From a2ee4189c0837b397709f1ab93aeccf9bc33fd1b Mon Sep 17 00:00:00 2001 From: Pierre-Yves Chibon Date: Thu, 22 Oct 2020 12:04:03 +0200 Subject: [PATCH] Rework the new initiative workflow Signed-off-by: Pierre-Yves Chibon --- modules/ROOT/pages/initiatives.adoc | 138 ++++++++++------------------ 1 file changed, 48 insertions(+), 90 deletions(-) diff --git a/modules/ROOT/pages/initiatives.adoc b/modules/ROOT/pages/initiatives.adoc index f0cae8f..e759c6d 100644 --- a/modules/ROOT/pages/initiatives.adoc +++ b/modules/ROOT/pages/initiatives.adoc @@ -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. +