cle/docs
36
0
Fork 0
Code Issues 3 Pull requests Projects Releases Packages Wiki Activity Actions

Rework the new initiative workflow

Browse source 
Signed-off-by: Pierre-Yves Chibon <pingou@pingoured.fr>
This commit is contained in:
Pierre-YvesChibon 2020-10-22 12:04:03 +02:00 • committed by pingou
commit a2ee4189c0
1 changed files with 49 additions and 91 deletions
Download patch file Download diff file Expand all files Collapse all files

138
modules/ROOT/pages/initiatives.adoc
View file

@ -7,128 +7,86 @@ CPE backlog.
== The Process
The process to bring something to the attention of the CPE team consists of
several steps:
The process to submit a new initiative to the CPE team to be potentially worked on is outlined below:
* Propose a new initiative; this proposal gives the “what” and “why” of the
work requested and send it to the product owner.
* The product owner reaches back and schedules some time with the requestor(s)
to go over the proposal to refine the details. We are looking to establish
why this initiative is important to do,what benefits it will bring to the
community, the technical details as the requestor sees them and their
estimated ‘need by’ date.
* Propose a new initiative by opening a ticket at
https://pagure.io/cpe/initiatives-proposal/new_issue - the proposal should
give the “what” and “why” of the work requestedd.
* The product owner will review your ticket, comment and potentially schedule
some time with the requestor(s) to go over the proposal to refine the details.
We are looking to establish why this initiative is important to do,what
benefits it will bring to the community, the technical details as the
requestor sees them and their estimated ‘need by’ date.
* Once we have established these requirements, the product owner reviews the
request with the technical leads of the team to scope the effort the initiative
will require from the team to complete. These details include skill sets needed,
hardware, storage, automation, dependant services that could be impacted by
changes made & how long they think this would take to complete.
request with the technical leads of the team to scope the effort the
initiative will require from the team to complete. These details include skill
sets needed, hardware, storage, automation, dependant services that could be
impacted by changes made & how long they think this would take to complete.
* This information is then reshared with the requestor to verify and sign off on
and then reviewed by the CPE review team to be accepted or rejected to our backlog.
and then reviewed by the CPE review team to be accepted or rejected to our
backlog.
* If rejected, the requestor is notified by the product owner.
* If accepted the proposal is added to our backlog queue and is reviewed before
quarterly planning dates to be considered as an option.
* If accepted, the proposal is added to our backlog queue and will be refined
until it is sufficiently scoped to be included in the list of initiatives to
be proposed at the quarterly planning.
* Projects that are moved from the backlog queue to the consideration queue and
are not chosen for that quarter may still be progressed in the next quarter, or
depending on project sizes and timelines, may be picked up by the team on free
cycles if they choose to work on this
are not chosen for that quarter may still be progressed in the next
quarter(s), or depending on project sizes and timelines, may be picked up by
the team on free cycles if they choose to work on this.
* The team leads, team management team and all the stakeholders review all the
proposals for the quarterly planning session during which they prioritize a number
of initiatives for the coming quarter.
* The management team forms the different project teams who will be working on the
different initiatives during the quarter.
* As the quarter progresses, the product owner will reach out to the requestor(s)
to sync with them on the progress of the initiatives.
proposals for the quarterly planning session during which they prioritize a
number of initiatives for the coming quarter.
* The management team forms the different project teams who will be working on
the different initiatives during the quarter.
* As the quarter progresses, the product owner will reach out to the
requestor(s) to sync with them on the progress of the initiatives.
.Initiatives flow
[#img-initiative-flow]
[caption="Figure 1: "]
image::CPE_initiatives_flow.jpg[The initiative flow,500,500]
=== Proposing a New Initiative
=== Writing Down a Requirements Document
To propose a new initiative, open a new ticket at
https://pagure.io/cpe/initiatives-proposal/new_issue and fill in the template
provided.
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:
That template is basically the _what_ and _why_ of your request and some other
information such as:
* _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
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].
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 dependencies for this initiative (dependencies on people, skillset,
other work/initiatives, etc...).
* Potential deadlines that could impact the initiative.
* Your definition of success
** The minimum required for this initiative to be considered a success and the
nice-to-have or really-nice-to-have you would like to see/have.
* Area and community concerned/impacted
=== First Decision Point: Is This Initiative for the CPE Team?
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,
in. If your initiative does not fit in the scope of our mission statement,
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.
has limited resources and needs to be careful on how they are spent. There may
be occasions where an initiative outside of our scope is accepted. Should this
happen, it will be at our team and management's discretion.
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.
The CPE team meets regularly to go over the proposed initiatives.
At this point, it will be decided if your initiative is accepted, or not, and if
necessary, appoint someone to work with you on refining this proposal.
=== Figuring out the Technical Solution
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 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 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
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 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
that will be worked on.
== Final Notes
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
we do 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.