Improve readability
Fix typos, grammar, wording, consistently use typographical quotes & apostrophes, and title case. Signed-off-by: Nils Philippsen <nils@redhat.com>
This commit is contained in:
parent
86f08a923b
commit
bc2c3d2fdc
6 changed files with 101 additions and 105 deletions
|
|
@ -1,3 +1,3 @@
|
|||
* xref:mission_statement.adoc[CPE's Mission]
|
||||
* xref:working_with_us.adoc[Working With the CPE Team]
|
||||
* xref:mission_statement.adoc[The CPE Team Mission]
|
||||
* xref:working_with_us.adoc[Working with Community Platform Engineering]
|
||||
** xref:initiatives.adoc[Initiatives]
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
= The Community Platform Engineering
|
||||
= The Community Platform Engineering Team
|
||||
|
||||
In 2017 the Fedora Engineering team merged with the CentOS Engineering team
|
||||
to form what is now called the Community Platform Engineering (CPE) team.
|
||||
|
|
|
|||
|
|
@ -5,25 +5,25 @@
|
|||
This document documents a proposed workflow to get new initiatives onto the CPE backlog.
|
||||
|
||||
|
||||
== The different steps
|
||||
== The Different Steps
|
||||
|
||||
The process to bring something to the attention of the CPE team is composed
|
||||
from different steps:
|
||||
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
|
||||
asked.
|
||||
* Based on the proposal the team then decides if it fits its mission
|
||||
statement and thus if it is worth pursuing, or if it would land on
|
||||
someone else to work on.
|
||||
* The CPE team together with the submitter work on figuring out the best
|
||||
approach to answer the demand.
|
||||
* 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.
|
||||
* 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
|
||||
whether they can commit to this initiative, and if so, a rough timeline
|
||||
for it.
|
||||
|
||||
|
||||
=== Write down a requirement 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.
|
||||
|
|
@ -35,16 +35,16 @@ It is basically the what and why of your request:
|
|||
* 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 what and why.
|
||||
proposal has been accepted based on its subject and the specified reason.
|
||||
|
||||
|
||||
=== Proposing a new initiative
|
||||
=== Proposing a New Initiative
|
||||
|
||||
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].
|
||||
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 in this ticket a few things:
|
||||
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
|
||||
|
|
@ -52,40 +52,39 @@ You will be asked in this ticket a few things:
|
|||
- potential deadlines that could impact the initiative
|
||||
|
||||
|
||||
=== First decision point: is this initiative for the CPE team?
|
||||
=== First Decision Point: Is This Initiative for the CPE Team?
|
||||
|
||||
Based on these information the CPE team will decide if this initiative is
|
||||
in the scope of the CPE team (ie: 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.
|
||||
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 for the CPE team, it does not mean your
|
||||
challenge is not worth pursuing but the CPE team has limited resources
|
||||
and needs to be careful on how they are spent.
|
||||
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 will meet to go over the initiative proposed. At
|
||||
this point, the CPE team will decide on accepting or not your initiative or
|
||||
if needed appoint someone to work with you to polish this document, improve
|
||||
the user-story, discuss with you what is in scope and what is out of scope.
|
||||
Every two weeks, the CPE 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 the technical solution
|
||||
=== Figuring out the Technical Solution
|
||||
|
||||
If your proposal is validate for the CPE team, you will be asked to
|
||||
collaborate with some CPE team representative to figure out the best
|
||||
technical solution to answer the use-case and users stories set in your
|
||||
requirements document.
|
||||
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 calling for feedback the communities affected by this
|
||||
This step may involve requesting feedback from the 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 possibly the solutions
|
||||
considered with why they were rejected (this could also be stored in a
|
||||
different document linked 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
|
||||
place linked from the requirement document).
|
||||
|
||||
|
||||
=== Final decision and prioritization
|
||||
=== 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
|
||||
|
|
@ -93,25 +92,25 @@ initiative is worth doing and what its priority status should be on the
|
|||
backlog of the team.
|
||||
|
||||
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 anywhere else, granted they document in the epic where they are
|
||||
tracking it.
|
||||
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).
|
||||
|
||||
If the initiative is not accepted by the CPE team, the ticket will be
|
||||
If the initiative is not accepted by the CPE team, the ticket will be
|
||||
closed as rejected with some explanations as to why.
|
||||
|
||||
Every quarter, the CPE team will meet to plan their work for the coming
|
||||
quarter. During this meeting, the team will go over the proposed and
|
||||
accepted initiatives, weight them against each other, prioritize them and
|
||||
pick the ones that will be worked on.
|
||||
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
|
||||
that will be worked on.
|
||||
|
||||
|
||||
== Conclusions
|
||||
|
||||
This new workflow will be a change from how the CPE team has worked up
|
||||
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 what we accept is properly limited in scope and time.
|
||||
Hopefully this will allow us to work on more initiatives and bring more
|
||||
beneficent changes to our communities.
|
||||
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
|
||||
to work on more initiatives and bring more beneficial changes to our
|
||||
communities.
|
||||
|
|
|
|||
|
|
@ -1,27 +1,27 @@
|
|||
= The CPE's Mission
|
||||
= The CPE Team Mission
|
||||
|
||||
== Our Mission
|
||||
|
||||
Our mission lays on three axes:
|
||||
Our mission rests on three axes:
|
||||
|
||||
.Our Missions
|
||||
.Our Mission
|
||||
[#img-mission]
|
||||
[caption="Figure 1: "]
|
||||
image::our_missions.jpg[Our Missions,500,500]
|
||||
image::our_missions.jpg[Our Mission,500,500]
|
||||
|
||||
* **Infrastructure**: 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 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.
|
||||
* **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 is facing is balancing these three axes.
|
||||
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?
|
||||
== What Is Our Mission Statement?
|
||||
|
||||
__The Community Platform Engineering Team is responsible for the
|
||||
infrastructure and services that support developing, building, and
|
||||
|
|
@ -34,12 +34,12 @@ including:__
|
|||
* __Tooling to enable all of the above__
|
||||
|
||||
|
||||
== Why a mission statement?
|
||||
== 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 coming): “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
|
||||
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,15 +1,14 @@
|
|||
= Working with Community Platform Engineering
|
||||
|
||||
|
||||
This document explains how to efficiently work with the CPE teams.
|
||||
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.
|
||||
|
||||
== Urgent Issues / Triage of incoming Issues
|
||||
== Urgent Issues / Triage of Incoming Issues
|
||||
|
||||
|
||||
Weekly a team member will be designated "oncall". You can find this
|
||||
person on IRC by using '.oncall' in any of our various channels.
|
||||
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
|
||||
|
|
@ -23,26 +22,24 @@ interrupt another team member.
|
|||
3. Triages incoming tickets for urgent items that need work outside
|
||||
of normal triage process.
|
||||
|
||||
== Normal operations requests
|
||||
== Normal Operation Requests
|
||||
|
||||
All normal operation requests should be filed as tickets, work items will not
|
||||
be accepted via private emails or IRC unless the oncall person determines them
|
||||
to be urgent.
|
||||
|
||||
All normal operations requests should be filed as tickets,
|
||||
work items will not be accepted via private emails or IRC unless
|
||||
the oncall person determines them to be urgent.
|
||||
== Normal Application Requests
|
||||
|
||||
== Normal applications requests
|
||||
All normal application bugs should be filed in the upstream tracker for the
|
||||
respective application where possible, unless it’s a deployment issue.
|
||||
|
||||
All normal application bugs should be filed in the upstream
|
||||
tracker for that application where possible, unless it's a
|
||||
deployment issue.
|
||||
|
||||
== Larger projects / feature requests
|
||||
== Larger Projects / Feature Requests
|
||||
|
||||
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
|
||||
== General Ticket Considerations
|
||||
|
||||
Please provide as much information as you can in your ticket to avoid
|
||||
back and forth for information. If you know your issue is going to
|
||||
|
|
@ -55,21 +52,21 @@ 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’s up to you as ticket filer to follow up on 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.
|
||||
|
||||
If you are unsure where to file a ticket or what information
|
||||
to place in it, please ask the oncall person or mail the team at https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org/
|
||||
If you are unsure where to file a ticket or which information you should
|
||||
provide, please ask the oncall person or mail the team at
|
||||
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org/
|
||||
|
||||
Your ticket may take a while to process depending on the work
|
||||
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
|
||||
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.
|
||||
|
||||
== 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
|
||||
|
|
@ -78,12 +75,12 @@ you on IRC for more interactive debugging/testing.
|
|||
== Direct emails
|
||||
|
||||
Email 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.
|
||||
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). Therefore, please avoid direct emails and update
|
||||
tickets with any information you want to add instead.
|
||||
|
||||
== RFC 1149
|
||||
|
||||
link:https://tools.ietf.org/html/rfc1149[Pidgeons are too slow] for most work
|
||||
items, instead update tickets. (and thanks for reading this far).
|
||||
items, update tickets instead (and thanks for reading this far).
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue