Various markup/style/grammar fixes
This commit is contained in:
parent
bd287e3b3f
commit
dbbddfb3d1
9 changed files with 239 additions and 263 deletions
|
|
@ -31,12 +31,12 @@ There are 20 people on this consolidated team. The breakdown looks like this:
|
|||
|
||||
* There is also one additional person working on projects internal to Red Hat
|
||||
|
||||
As you can see this team is both quite diverse as well as limited. For
|
||||
example, we do not have dedicated database adminstrators or network engineers
|
||||
As you can see, this team is both quite diverse as well as limited. For
|
||||
example, we do not have dedicated database administrators or network engineers
|
||||
even though most of our application is one or the other when not both.
|
||||
|
||||
For these reasons we need to be careful on how our limited resources are
|
||||
spent. The team has therefore defined a xref:mission_statement.adoc[Mission
|
||||
spent. The team has therefore defined a xref:index.adoc[Mission
|
||||
Statement] for itself, allowing to focus its work in certain areas.
|
||||
|
||||
We have also written a document explaining xref:working_with_us.adoc[How to
|
||||
|
|
|
|||
|
|
@ -1,8 +1,11 @@
|
|||
:experimental:
|
||||
= Working with Community Platform Engineering in CentOS
|
||||
|
||||
|
||||
This document explains how to efficiently work with the CPE team.
|
||||
Your close attention to this document will help both you and us
|
||||
do the work you are asking us to do.
|
||||
|
||||
`This document is a work in progress and should be updated soon`.
|
||||
[NOTE]
|
||||
====
|
||||
This document is a work in progress and will be updated soon.
|
||||
====
|
||||
|
|
|
|||
|
|
@ -1,61 +1,75 @@
|
|||
:experimental:
|
||||
= Working with Community Platform Engineering in Fedora
|
||||
|
||||
This document explains how to efficiently work with the CPE team.
|
||||
Your close attention to this document will help both you and us
|
||||
do the work you are asking us to do.
|
||||
|
||||
|
||||
== Our Workflow
|
||||
|
||||
1. Is your issue/problem related to security of an application or service we run?
|
||||
* send email to infra-security@fedoraproject.org
|
||||
. Is your issue/problem related to security of an application or service we
|
||||
run?
|
||||
* send an email to `infra-security` @ fedoraproject.org
|
||||
|
||||
2. Is your issue/problem urgent? (An important service is down, you need a change asap)
|
||||
or is your issue/problem such that you cannot file a ticket (authentication, no account, ticketing system down)
|
||||
* On irc, freenode, /join #fedora-admin and say _.oncall_ and explain the issue to the oncall person.
|
||||
* If no answer:
|
||||
** If you cannot authenticate to `pagure.io`, send an email to `admin` @ fedoraproject.org
|
||||
** Otherwise: go to next step.
|
||||
. Is your issue/problem urgent? (An important service is down, you need
|
||||
a change asap) or is your issue/problem such that you cannot file a ticket
|
||||
(authentication, no account, ticketing system down)
|
||||
* On IRC (irc.freenode.net) join the `#fedora-admin` channel, say _.oncall_,
|
||||
and explain the issue to the oncall person.
|
||||
* If no answer:
|
||||
** If you cannot authenticate to link:https://pagure.io/[], send an email
|
||||
to `admin` @ fedoraproject.org
|
||||
** Otherwise: go to next step.
|
||||
|
||||
3. File a ticket in https://pagure.io/fedora-infrastructure/issues/ with as much information
|
||||
as you think will be needed to handle your issue. This initial ticket will be made in the
|
||||
_Needs review_ state. Please note if there is a deadline or this issue blocks you.
|
||||
* your ticket will be reviewed within 48 hours. (usually sooner)
|
||||
* There is no need to ping team members or notify us about the newly filed ticket.
|
||||
. File a ticket in link:https://pagure.io/fedora-infrastructure/issues/[] with
|
||||
as much information as you think will be needed to handle your issue. This
|
||||
initial ticket will be made in the _Needs review_ state. Make sure to note if
|
||||
there is a deadline or if this issue blocks you.
|
||||
* Your ticket will be reviewed within 48 hours at most; usually sooner.
|
||||
* There is no need to ping team members or notify us about the newly filed
|
||||
ticket.
|
||||
|
||||
4. your ticket will be triaged by a team member and moved to a new state:
|
||||
* If it's moved to _Waiting on asignee_ it's waiting for a team member to start work on it.
|
||||
* If it's moved to _Waiting on reporter_ it means that you need to answer questions posed in the ticket before it can be worked on.
|
||||
* f the ticket is closed with _initiative_, See xref:initiatives.adoc[New Initiative Workflow]
|
||||
* If the ticket is otherwise closed, it will be with a explaination from a team member.
|
||||
. Your ticket will be triaged by a team member and moved to a new state:
|
||||
* If it's moved to _Waiting on asignee_ it's waiting for a team member to
|
||||
start working on it.
|
||||
* If it's moved to _Waiting on reporter_ it means that you need to answer
|
||||
questions posed in the ticket before it can be worked on.
|
||||
* If the ticket is closed with _initiative_, see
|
||||
xref:initiatives.adoc[New Initiative Workflow].
|
||||
* If the ticket is otherwise closed, it will be with a explanation from
|
||||
a team member.
|
||||
|
||||
5. If you have an update to your issue/task or want to know when it might be worked on:
|
||||
* comment in the ticket adding that information or asking for timeframe.
|
||||
. If you have an update to your issue/task or want to know when it might be
|
||||
worked on:
|
||||
* comment in the ticket adding that information or asking for time frame.
|
||||
|
||||
6. When someone is available, your ticket will be assigned to someone to work on.
|
||||
* Watch for progress reports/ticket being marked done.
|
||||
. When someone is available, your ticket will be assigned to someone to work
|
||||
on.
|
||||
* Watch for progress reports/ticket being marked done.
|
||||
|
||||
7. If the work is not fully completed as required, please re-open the ticket and indicate this.
|
||||
* go back to step 6 for additional work.
|
||||
. If the work is not fully completed as required, please re-open the ticket
|
||||
and indicate this.
|
||||
* Go back to the previous step for additional work.
|
||||
|
||||
== The "Oncall" Role in Our Team
|
||||
|
||||
== The oncall role in our team
|
||||
One CPE team member is always designated “oncall”. The assigned person changes
|
||||
every week. You can find who the currently assigned person is on IRC by using
|
||||
`.oncall` in any of our various IRC channels, such as `#fedora-admin` on
|
||||
FreeNode.
|
||||
|
||||
Weekly a team member will be designated “oncall”. You can find this
|
||||
person on IRC by using _.oncall_ in any of our various IRC channels.
|
||||
When available, this person:
|
||||
|
||||
1. Accepts urgent work items for the team, for example a important
|
||||
or high SLE service is down or causing issues. A ticket should
|
||||
be filed by the reporter or the oncall to track this work in any case.
|
||||
. Accepts urgent work items for the team, such as an important
|
||||
or high SLE service being down or causing issues. A ticket should
|
||||
be filed by the reporter or the oncall person to track this work in any case.
|
||||
|
||||
2. Shields other team members from distracting pings and less
|
||||
urgent tickets, deciding when an issue is important enough to
|
||||
interrupt another team member.
|
||||
|
||||
3. Triages incoming tickets for urgent items that need work outside
|
||||
of normal triage process.
|
||||
. Shields other team members from distracting pings and less
|
||||
urgent tickets, deciding when an issue is important enough to
|
||||
interrupt another team member.
|
||||
|
||||
. Triages incoming tickets for urgent items that need work outside
|
||||
of normal triage process.
|
||||
|
||||
== Initiatives
|
||||
|
||||
|
|
@ -63,7 +77,6 @@ All tasks involving new applications, major deployments, major development work
|
|||
or the like will be asked to follow the xref:initiatives.adoc[New Initiative
|
||||
Workflow]. It will then be scoped and prioritized from there.
|
||||
|
||||
|
||||
== General Ticket Considerations
|
||||
|
||||
Please provide as much information as you can in your ticket to avoid
|
||||
|
|
@ -72,41 +85,42 @@ cause a lot of discussion, start a mailing list thread for that.
|
|||
|
||||
Make sure your ticket:
|
||||
|
||||
* explains the problem or issue you are having, with URLs where
|
||||
possible to the services or applications involved.
|
||||
* tells us how important or urgent this is to you.
|
||||
* includes any error messages or output you see.
|
||||
* Explains the problem or issue you are having, with URLs where
|
||||
possible to the services or applications involved.
|
||||
* Tells us how important or urgent this is to you.
|
||||
* Includes any error messages or output you see.
|
||||
|
||||
It's up to you as ticket filer to follow your ticket, provide information
|
||||
that is asked for and keep us aware of any urgency you may have, do not
|
||||
simply file and forget your ticket.
|
||||
It is your responsibility as ticket reporter to follow your ticket, provide
|
||||
information that is asked for, and keep us aware of any urgency you may have.
|
||||
Do not simply file and forget your ticket.
|
||||
|
||||
Your ticket may take a while to process, depending on the work
|
||||
that the team has and how important we think it is. If your ticket
|
||||
Your ticket may take a while to process, depending on the current workload
|
||||
of the team has and how important we think it is. If your ticket
|
||||
is blocking you, make sure you note that in the ticket, but keep in
|
||||
mind that we may be working on tickets that are blocking more people.
|
||||
|
||||
mind that we may already be working on tickets that are blocking more people.
|
||||
|
||||
== IRC
|
||||
|
||||
IRC is a great way to communicate, but please do not ping team members directly.
|
||||
Instead, update your ticket with any new information you have and when the
|
||||
team member(s) working on that issue have time/availability they may contact
|
||||
you on IRC for more interactive debugging/testing.
|
||||
|
||||
IRC is a great way to communicate, but please do not ping team members
|
||||
directly. Instead, update your ticket with any new information you have and
|
||||
when the team member(s) working on that issue have time/availability, they
|
||||
may contact you on IRC for more interactive debugging/testing.
|
||||
|
||||
== Direct emails
|
||||
|
||||
Email is also a great communication method, but if you mail work items or
|
||||
E-mail is also a great communication method, but if you mail work items or
|
||||
information to one person directly, they cannot easily hand off the issue,
|
||||
you must wait for them to have time to address the issue (when others could
|
||||
perhaps have already solved it, etc). So, please avoid direct emails and instead
|
||||
update tickets with any information you want to add.
|
||||
|
||||
perhaps have already solved it, etc). So, please avoid direct emails and
|
||||
instead update tickets with any information you want to add.
|
||||
|
||||
== RFC 1149
|
||||
|
||||
link:https://tools.ietf.org/html/rfc1149[Pidgeons are too slow] for most work
|
||||
items, instead update tickets.
|
||||
link:https://tools.ietf.org/html/rfc1149[Pigeons are too slow] for most work
|
||||
items, and require facilities (e.g. dovecots) that most team members do not
|
||||
have. Even if the oncall member does have a free dovecot, feed, and is trained
|
||||
in handling carrier pigeons, sending a pigeon to a single team member has the
|
||||
same problems as using IRC or email for the same purpose, which means tickets
|
||||
are still the correct way to report problems.
|
||||
|
||||
Thank you for reading this entire document!
|
||||
In other words, please don't send us any birds.
|
||||
|
|
|
|||
|
|
@ -1,3 +1,4 @@
|
|||
:experimental:
|
||||
= The Community Platform Engineering Team
|
||||
|
||||
The Community Platform Engineering Team (CPE) is a Red Hat team dedicated
|
||||
|
|
@ -19,25 +20,25 @@ image::our_missions.jpg[Our Mission,500,500]
|
|||
* **Application maintenance**: For the applications that we maintain, we work
|
||||
on bug fixes, new features and community development.
|
||||
* **Initiatives**: For a limited time and scope we dedicate some of our
|
||||
engineers and adminstrators to initiatives deemed important and beneficial to
|
||||
the communities we are involved in.
|
||||
engineers and administrators to initiatives deemed important and beneficial
|
||||
to the communities we are involved in.
|
||||
|
||||
One of the key challenges this team faces is balancing these three axes.
|
||||
For this reason, we worked on the following Mission Statement.
|
||||
For this reason, we developed the following Mission Statement.
|
||||
|
||||
== Our responsibilities
|
||||
== Our Responsibilities
|
||||
|
||||
Our responsibilities are scoped in our mission statement:
|
||||
|
||||
=== Our Mission Statement
|
||||
|
||||
__The Community Platform Engineering Team is responsible for the
|
||||
infrastructure and services that support developing, building, and
|
||||
releasing of Fedora and CentOS platform artifacts and deliverables,
|
||||
including:__
|
||||
infrastructure and services that support developing, building, and releasing
|
||||
of Fedora and CentOS platform artifacts and deliverables, including:__
|
||||
|
||||
* __Hosting, automating, monitoring and maintaining infrastructure components__
|
||||
* __Service monitoring and lifecycle management of services hosted within our infrastructure__
|
||||
* __Service monitoring and lifecycle management of services hosted within our
|
||||
infrastructure__
|
||||
* __Feature development for infrastructure-related initiatives__
|
||||
* __Tooling to enable all of the above__
|
||||
|
||||
|
|
|
|||
|
|
@ -1,42 +1,42 @@
|
|||
:experimental:
|
||||
:toc:
|
||||
= New Initiative Workflow
|
||||
|
||||
:toc:
|
||||
This document documents a proposed workflow to get new initiatives onto the
|
||||
CPE backlog.
|
||||
|
||||
This document documents a proposed workflow to get new initiatives onto the CPE backlog.
|
||||
|
||||
|
||||
== The Different Steps
|
||||
== The Process
|
||||
|
||||
The process to bring something to the attention of the CPE team consists of
|
||||
several steps:
|
||||
|
||||
* Propose a new initiative; this proposal gives the “what” and “why” of the
|
||||
work requested.
|
||||
* Based on the proposal, the team then decides if it fits its mission
|
||||
statement and thus if it is worth being pursued by the team, or if this work
|
||||
falls under the responsibility of someone else.
|
||||
* For work considered in scope, the CPE team together with the submitter work
|
||||
on figuring out the best approach to fulfill the request.
|
||||
* The team will review and discuss the proposal and determine whether it fits
|
||||
its mission statement and thus if it is worth being pursued by the team, or
|
||||
whether this work falls under the responsibility of someone else.
|
||||
* If the CPE team determines the proposal to be in line with the
|
||||
xref:index.adoc[mission statement], the team will work together with the
|
||||
submitter on figuring out the best approach to fulfill the request.
|
||||
* Based on the estimated amount of work, the initiatives currently in
|
||||
progress, priorities, and return on investment, the CPE team decides
|
||||
whether they can commit to this initiative, and if so, a rough timeline
|
||||
for it.
|
||||
progress, priorities, and return on investment, the CPE team decides whether
|
||||
they can commit to this initiative, and if so, a rough timeline for it.
|
||||
|
||||
=== Writing Down a Requirements Document
|
||||
|
||||
=== Writing Down a Requirement Document
|
||||
|
||||
The CPE team has link:https://hackmd.io/@pingou/rJd0HaipV[prepared a template]
|
||||
for you to use to write down your requirement document.
|
||||
The CPE team has prepared a link:https://hackmd.io/@pingou/rJd0HaipV[template]
|
||||
for you to use to write down your requirements document.
|
||||
//TODO: make sure this gets updated when the GDoc is
|
||||
|
||||
This document is divided into two parts, the first part is yours to fill.
|
||||
It is basically the what and why of your request:
|
||||
It is basically the _what_ and _why_ of your request:
|
||||
|
||||
* What do you want the CPE team to work on?
|
||||
* Why do you think it is worth for the CPE team to work on it?
|
||||
|
||||
The second part will be filled out later by you and the CPE team once your
|
||||
proposal has been accepted based on its subject and the specified reason.
|
||||
* _What_ do you want the team to work on?
|
||||
* _Why_ do you think it is worth doing?
|
||||
|
||||
Once your proposal has been accepted based on its subject and the specified
|
||||
reason, the team will contact you and you will fill out the second part of
|
||||
the template together.
|
||||
|
||||
=== Proposing a New Initiative
|
||||
|
||||
|
|
@ -44,73 +44,67 @@ Once you have written down your requirement document, submit it to the CPE
|
|||
team for review. To do this, simply open a ticket on the
|
||||
link:https://pagure.io/cpe/initiatives-proposal[CPE-initiatives issue tracker].
|
||||
|
||||
You will be asked a few things in this ticket:
|
||||
|
||||
- a link to your requirement document
|
||||
- potential dependencies for this initiative (dependencies on people or
|
||||
other initiatives)
|
||||
- potential deadlines that could impact the initiative
|
||||
The ticket should contain the following items:
|
||||
|
||||
* A link to your requirements document.
|
||||
* Potential dependencies for this initiative (dependencies on people or other
|
||||
initiatives).
|
||||
* Potential deadlines that could impact the initiative.
|
||||
|
||||
=== First Decision Point: Is This Initiative for the CPE Team?
|
||||
|
||||
Based on these information the CPE team will decide if this initiative is in
|
||||
scope for it (i.e. does it fit its xref:mission_statement.adoc[Mission
|
||||
Statement]), but also if there is a clear benefit for the communities the CPE
|
||||
team is involved in.
|
||||
|
||||
If your initiative doesn’t fit in the purview of the CPE team, it does not mean
|
||||
your challenge is not worth pursuing but that the CPE team has limited
|
||||
resources and needs to be careful on how they are spent.
|
||||
|
||||
Every two weeks, the CPE team will meet to go over the proposed initiatives. At this
|
||||
point, the CPE team will decide if it accepts your initiative or, if necessary,
|
||||
appoint someone who will work with you to polish this document, improve the
|
||||
user-story, and discuss with you what is in scope and what isn’t.
|
||||
Based on the information provided in the ticket, the CPE team will consider
|
||||
whether the initiative is in scope of the xref:index.adoc[Mission Statement],
|
||||
and if there is a clear benefit for the communities the CPE team is involved
|
||||
in. If your initiative does not fit in the process outline of the CPE team,
|
||||
it does not mean your challenge is not worth pursuing - but that the CPE team
|
||||
has limited resources and needs to be careful on how they are spent.
|
||||
|
||||
Every two weeks, the CPE team will meet to go over the proposed initiatives.
|
||||
At this point, the CPE team will decide if it accepts your initiative, or, if
|
||||
necessary, appoint someone who will work with you to polish this document,
|
||||
improve the user-story, and discuss with you what is in scope and what isn’t.
|
||||
|
||||
=== Figuring out the Technical Solution
|
||||
|
||||
If your proposal fits for the CPE team, you will be asked to collaborate with a
|
||||
team representative to figure out the best technical solution to answer the
|
||||
use-case and user stories set in your requirements document.
|
||||
|
||||
This step may involve requesting feedback from the communities affected by this
|
||||
change.
|
||||
If your proposal is in line with CPE's mission, you will be asked to
|
||||
collaborate with a team representative to figure out the best technical
|
||||
solution to answer the use-case and user stories set in your requirements
|
||||
document. This step may involve requesting input from any communities
|
||||
affected by this change.
|
||||
|
||||
The second part of the requirement document should be kept up to date to
|
||||
reflect the technical solution of choice and, if applicable, document other
|
||||
approaches and why they were rejected (this could also be stored in a different
|
||||
reflect the technical solution of choice, and, if applicable, document other
|
||||
approaches and why they were rejected (this may also be stored in a different
|
||||
place linked from the requirement document).
|
||||
|
||||
|
||||
=== Final Decision and Prioritization
|
||||
|
||||
Finally, once the two parts of the requirement document have been filled,
|
||||
the CPE team and its stakeholder will be consulted to decide if the
|
||||
initiative is worth doing and what its priority status should be on the
|
||||
backlog of the team.
|
||||
the CPE team and its stakeholders will be consulted to decide if the
|
||||
initiative is worth doing and what its priority status should be in the team's
|
||||
backlog.
|
||||
|
||||
If the initiative is approved, the ticket will be closed as accepted and an
|
||||
If the initiative is approved, the ticket will be closed as _accepted_ and an
|
||||
epic will be created in the
|
||||
link:https://teams.fedoraproject.org/project/pingou-cpe-dev-1/epics[CPE Taiga
|
||||
board]. It will then be up to the team working on this epic to track their
|
||||
work in Taiga or elsewhere (which should be documented in the epic).
|
||||
//TODO: Fix the above link
|
||||
|
||||
If the initiative is not accepted by the CPE team, the ticket will be
|
||||
closed as rejected with some explanations as to why.
|
||||
closed as _rejected_ with an explanation as to why.
|
||||
|
||||
Every quarter of the year, the CPE team will meet to plan their work for the
|
||||
next one. During this meeting, the team will go over the proposed and accepted
|
||||
initiatives, weigh them against each other, prioritize them and pick the ones
|
||||
next one. During this meeting, the team will go over the proposed and accepted
|
||||
initiatives, weigh them against each other, prioritize them, and pick the ones
|
||||
that will be worked on.
|
||||
|
||||
== Final Notes
|
||||
|
||||
== Conclusions
|
||||
|
||||
This new workflow will be a change from how the CPE team has worked until now.
|
||||
Its core idea is to maximize the output of the team to the community. We are
|
||||
not able to accept everything and anything and we want to make sure that what
|
||||
we accept is properly limited in scope and time. Hopefully this will allow us
|
||||
This new workflow is a change from how the CPE team has worked until now.
|
||||
The core idea is to maximize the output of the team to the community. We are
|
||||
not able to accept everything and anything, and we want to make sure that what
|
||||
we accept is properly limited in scope and time. Hopefully this will allow us
|
||||
to work on more initiatives and bring more beneficial changes to our
|
||||
communities.
|
||||
|
|
|
|||
|
|
@ -1,45 +0,0 @@
|
|||
= The CPE Team Mission
|
||||
|
||||
== Our Mission
|
||||
|
||||
Our mission rests on three axes:
|
||||
|
||||
.Our Mission
|
||||
[#img-mission]
|
||||
[caption="Figure 1: "]
|
||||
image::our_missions.jpg[Our Mission,500,500]
|
||||
|
||||
* **Infrastructure**: To provide power and ping to the different systems that
|
||||
are used by our community.
|
||||
* **Application maintenance**: For the applications that we maintain, we work
|
||||
on bug fixes, new features and community development.
|
||||
* **Initiatives**: For a limited time and scope we dedicate some of our
|
||||
engineers and adminstrators to initiatives deemed important and beneficial to
|
||||
the communities we are involved in.
|
||||
|
||||
One of the key challenges this team faces is balancing these three axes.
|
||||
For this reason, we worked on the following Mission Statement.
|
||||
|
||||
|
||||
== What Is Our Mission Statement?
|
||||
|
||||
__The Community Platform Engineering Team is responsible for the
|
||||
infrastructure and services that support developing, building, and
|
||||
releasing of Fedora and CentOS platform artifacts and deliverables,
|
||||
including:__
|
||||
|
||||
* __Hosting, automating, monitoring and maintaining infrastructure components__
|
||||
* __Service monitoring and lifecycle management of services hosted within our infrastructure__
|
||||
* __Feature development for infrastructure-related initiatives__
|
||||
* __Tooling to enable all of the above__
|
||||
|
||||
|
||||
== Why a Mission Statement?
|
||||
|
||||
A mission statement means the team shares a common vision about what our
|
||||
work is or should be. It gives us clear boundaries for our work and it
|
||||
helps us having a critical view on our work (current or in the future): “Does
|
||||
this fit our mission statement?”. With this in mind we can focus on bringing
|
||||
more value to the community. In other words, we want to maximize our value and
|
||||
impact in a targeted mission rather than having limited impact on a broad
|
||||
spectrum.
|
||||
|
|
@ -1,10 +1,12 @@
|
|||
:experimental:
|
||||
:toc:
|
||||
//TODO: this file keeps talking about Fedora Infra. We should either change it to CPE, or have a separate SLE doc for CentOS if there's a difference in SLEs.
|
||||
= Service Level Expectations
|
||||
|
||||
The CPE team does not have any agreement, or contract about the availability
|
||||
of its different services. However, we do try our best to keep the services
|
||||
running and as a result you can have some expectations as to what we will
|
||||
do to this extent.
|
||||
|
||||
The CPE team does not have any formal agreement or contract regarding the
|
||||
availability of its different services. However, we do try our best to keep
|
||||
services running, and as a result, you can have some expectations as to what
|
||||
we will do to this extent.
|
||||
|
||||
== Primary Business Hours
|
||||
|
||||
|
|
@ -27,18 +29,18 @@ the availability of staff.
|
|||
* Interact with community members with respect and courtesy.
|
||||
* Work with community members to get accurate and thorough documentation of
|
||||
incidents, problems, or feature requests.
|
||||
* When possible resolve the problem as soon as acknowledged.
|
||||
* Communicate clearly estimated resolution times.
|
||||
* Resolve reported problems as soon as acknowledged if possible.
|
||||
* Clearly communicate estimated resolution times.
|
||||
* Move items which can not be resolved within a reasonable time to future
|
||||
feature requests or close out.
|
||||
|
||||
=== Community Member to Fedora Infrastructure
|
||||
=== Community Members to Fedora Infrastructure
|
||||
|
||||
* Give full and detailed reports of the problem or requested service.
|
||||
* Provide full and detailed reports of the problem or requested service.
|
||||
* Provide clear and complete contact information and times when available.
|
||||
* Leave alternative contacts who can also be available in case of vacation
|
||||
or other emergencies.
|
||||
* When contacted by Fedora IT, respond back within 5 business days
|
||||
* When contacted by Fedora IT, respond back within 5 business days.
|
||||
|
||||
=== Fedora Infrastructure to Fedora Infrastructure
|
||||
|
||||
|
|
@ -52,34 +54,35 @@ the availability of staff.
|
|||
|
||||
== Definition of Service Priorities
|
||||
|
||||
The general design of service priorities is that of concentric circles where
|
||||
The general design of service priorities is that of concentric circles, where
|
||||
items rely on services in their own circle or a circle below them.
|
||||
//TODO: could use an image
|
||||
|
||||
1. Critical services are ones which Fedora Infrastructure will work on 24x7
|
||||
with 52 week coverage if an unplanned outage occurs. Services will be
|
||||
configured to be highly available with an estimated planned/unplanned
|
||||
uptime of 95%. Response time should be within 1 hour.
|
||||
2. Important services are ones which Fedora Infrastructure will work to be
|
||||
available 24x7 with 50 week coverage. Response times during primary hours
|
||||
should be 1 hour and outside of it should be 4 hours.
|
||||
3. Normal services are ones which Fedora Infrastructure will work to be
|
||||
available during primary work hours. Problems outside of these hours will
|
||||
be looked at as people are available. The services may be available
|
||||
outside of these but are of a lower priority than important services.
|
||||
4. Low priority services are ones which are not critical or important for
|
||||
the primary function of Fedora Infrastructure. They will be worked on and
|
||||
looked at during primary business hours. Response times should be within
|
||||
1 business day.
|
||||
5. Third Party services are ones which Fedora Infrastructure has outsourced
|
||||
tools and services to. Uptimes, service hours, and coverage are dictated
|
||||
by the third party. Depending on the type of problem, Fedora Infrastructure
|
||||
will act as an intermediary or in the case of tools like retrace and COPR
|
||||
direct the user to talk with the service owners.
|
||||
6. Deprecated services are ones which Fedora Infrastructure are no longer
|
||||
putting resources into. This may be because the project has completed its
|
||||
mission, the upstream software is dead, or the original reasons for the
|
||||
product are available. Problems with these services will be looked at
|
||||
during primary business hours. Responses may be mostly "Will Not Fix".
|
||||
. *Critical* services are ones which Fedora Infrastructure will work on 24x7
|
||||
with a 52 week coverage if an unplanned outage occurs. Services will be
|
||||
configured to be highly available with an estimated planned/unplanned
|
||||
uptime of 95%. Response time should be within 1 hour.
|
||||
. *Important* services are ones which Fedora Infrastructure will work to be
|
||||
available 24x7 with a 50 week coverage. Response times during primary hours
|
||||
should be 1 hour, and outside of it should be 4 hours.
|
||||
. *Normal* services are ones which Fedora Infrastructure will work to be
|
||||
available during primary work hours. Problems outside of these hours will
|
||||
be looked at as people are available. The services may be available
|
||||
outside of these but are of a lower priority than important services.
|
||||
. *Low priority* services are ones which are not critical or important for
|
||||
the primary function of Fedora Infrastructure. They will be worked on and
|
||||
looked at during primary business hours. Response times should be within
|
||||
1 business day.
|
||||
. *Third Party* services are ones which Fedora Infrastructure has outsourced
|
||||
tools and services to. Uptimes, service hours, and coverage are dictated
|
||||
by the third party. Depending on the type of problem, Fedora Infrastructure
|
||||
will act as an intermediary, or in the case of tools like retrace and COPR,
|
||||
direct the user to talk with the service owners.
|
||||
. *Deprecated* services are ones which Fedora Infrastructure are no longer
|
||||
putting resources into. This may be because the project has completed its
|
||||
mission, the upstream software is dead, or the original reasons for the
|
||||
product are available. Problems with these services will be looked at
|
||||
during primary business hours. Responses may be mostly "Will Not Fix".
|
||||
|
||||
== Limitations on Support
|
||||
|
||||
|
|
@ -96,36 +99,38 @@ items rely on services in their own circle or a circle below them.
|
|||
|
||||
== Glossary
|
||||
|
||||
* **Planned outage**: A planned outage is one that is announced with enough
|
||||
time to give most user's the ability to plan around it.
|
||||
* **Planned outage**: A planned outage is one that is announced sufficiently
|
||||
ahead of time to allow most users to plan around it.
|
||||
|
||||
* **Unplanned outage**: An outage that occurs suddenly without proper
|
||||
allowance for users to plan around it.
|
||||
|
||||
* **Scheduled outage**: An outage which has been scheduled to occur but may
|
||||
* **Scheduled outage**: An outage which has been scheduled to occur, but may
|
||||
not have been announced with enough time for users to plan around it.
|
||||
|
||||
* **High Availability**: Systems are available during specified operating
|
||||
hours with any unplanned outages 'masked' by other tools.
|
||||
|
||||
* **Continuous Operations**: Systems are available 24 hours a day, 7 days a
|
||||
week with no scheduled outages. Unplanned outages are possible during this time.
|
||||
* **Continuous Operations**: Systems are available 24 hours a day, 7 days
|
||||
a week, with no scheduled outages. Unplanned outages are possible during
|
||||
this time.
|
||||
|
||||
* **Continuous Availability**: Systems or applications are available 24x7
|
||||
with no planned or unplanned outages. This is a combination of high
|
||||
availability and continuous operations.
|
||||
availability and continuous operations.
|
||||
|
||||
* **Level of availability**:
|
||||
[options="header"]
|
||||
|======================================
|
||||
|Percentage | Max outage time per day |
|
||||
| 90% | 144.0 minutes |
|
||||
| 95% | 72.0 minutes |
|
||||
| 99% | 14.4 minutes |
|
||||
| 99.9% | 1.4 minutes |
|
||||
|======================================
|
||||
|
||||
* **Commited Hours of Availability**: Hours that an organization will have
|
||||
[options=header]
|
||||
|===
|
||||
|Percentage | Max outage time per day
|
||||
| 90% | 144.0 minutes
|
||||
| 95% | 72.0 minutes
|
||||
| 99% | 14.4 minutes
|
||||
| 99.9% | 1.4 minutes
|
||||
|===
|
||||
|
||||
* **Committed Hours of Availability**: Hours that an organization will have
|
||||
staff available to help deal with issues with systems, services, and
|
||||
applications. Also known as "Regular Business Hours"
|
||||
|
||||
|
|
@ -138,7 +143,7 @@ items rely on services in their own circle or a circle below them.
|
|||
* **Resolution Update**: The frequency of updates to tickets
|
||||
|
||||
== Estimated Time of Resolution:
|
||||
|
||||
//TODO: this is missing the actual times
|
||||
By priority Levels:
|
||||
|
||||
* **Emergency**: Problems which are site wide, and affect the core functions
|
||||
|
|
|
|||
|
|
@ -1,41 +1,45 @@
|
|||
:experimental:
|
||||
= Working with Community Platform Engineering
|
||||
|
||||
This document explains the basic principles of working with the CPE team.
|
||||
These rules are necessary to allow the team to operate efficiently and to
|
||||
allow us to plan our work.
|
||||
|
||||
The general rules are:
|
||||
|
||||
* Do not ping a single person
|
||||
|
||||
+
|
||||
By doing this you reduce the number of people having access to your request
|
||||
drastically, meaning, if that person is busy with something else, your
|
||||
request may take much longer to be processed.
|
||||
|
||||
* If it is not in a ticket, it did not happen
|
||||
|
||||
We need to have everything in tickets. This helps sharing knowledge within
|
||||
the team but also tracking issues and potentially find the ones that are
|
||||
recurring frequently and may thus be an indicator of something we need to
|
||||
fix.
|
||||
|
||||
Even if you have discussed something on IRC or in a corridor with someone
|
||||
+
|
||||
We need to have everything in tickets. This helps us share knowledge within
|
||||
the team, efficiently track our workload, and identify recurring issues which
|
||||
may be indicative of an underlying problem we need to fix in a more systemic
|
||||
manner.
|
||||
+
|
||||
Even if you have discussed something on IRC, or in a corridor with someone
|
||||
in the team, you want to log the discussion and its outcome in a ticket so
|
||||
we can get back to it in 2 months or 3 when we need to investigate why this
|
||||
we can get back to it later when we need to investigate why this
|
||||
change was made.
|
||||
|
||||
* When you cannot open a ticket
|
||||
|
||||
+
|
||||
There are a few cases where it is acceptable to send an email or to reach
|
||||
directly to people, for example if you cannot access or authenticate to the
|
||||
ticket tracking system :)
|
||||
|
||||
+
|
||||
In this case, you do not want to send your email or ping a single person
|
||||
(cf the first point above).
|
||||
|
||||
- In Fedora, you can use the email: `admin` @ fedoraproject.org
|
||||
- In CentOS, you can contact the sysadmins on the `#centos-devel` channel on irc.freenode.net
|
||||
|
||||
+
|
||||
- In Fedora, you can use the email `admin` @ fedoraproject.org
|
||||
- In CentOS, you can contact the sysadmins on the `#centos-devel` channel on `irc.freenode.net`
|
||||
|
||||
Both projects have their own, additional, processes for their day to day work,
|
||||
you can find them there:
|
||||
- xref:day_to_day_fedora.adoc[for Fedora]
|
||||
- xref:day_to_day_centos.adoc[for CentOS]
|
||||
which you can find in:
|
||||
|
||||
- xref:day_to_day_fedora.adoc[Day to day for Fedora]
|
||||
|
||||
- xref:day_to_day_centos.adoc[Day to day for CentOS]
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue