From Fedora Project Wiki
 
(44 intermediate revisions by 5 users not shown)
Line 1: Line 1:
= Responsibility Matrix for the Two Week Atomic Fedora Change =
= Responsibility Matrix for the Two Week Atomic Fedora Change =


This is a [https://en.wikipedia.org/wiki/Responsibility_assignment_matrix RACI matrix] for tasks required to implement [[Changes/Two Week Atomic|Two Week Atomic]]. We'll also use it for basic progress tracking, because one wiki table is less evil than two.
This is a [https://en.wikipedia.org/wiki/Responsibility_assignment_matrix RACI matrix] for tasks required to implement [[Changes/Two Week Atomic|Two Week Atomic]]. Work is tracked in Taiga: http://taiga.cloud.fedoraproject.org/project/acarter-fedora-docker-atomic-tooling/wiki/home
 
== Is this current? ==
 
It is, as of {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}}.


== Definitions ==
== Definitions ==


Here, we're using what Wikipedia calls "[https://en.wikipedia.org/wiki/Responsibility_assignment_matrix#RACI_.28alternative_scheme.29 RACI (alternative scheme)]:
Here, we're using what Wikipedia calls "[https://en.wikipedia.org/wiki/Responsibility_assignment_matrix#RACI_.28alternative_scheme.29 RACI (alternative scheme)]":




:; ''Responsible''
:; ''Responsible''
:: The person responsible for the performance of the task. There should be exactly one person with this assignment for each task.
:: The person responsible for the performance of the task. There should be exactly one person with this assignment for each task. People in the Assists column for the overall task may be Responsible for subtasks, but it's the top-level Responsible person's job to make sure those subtasks do not get blocked.


:; ''Assists''
:; ''Assists''
:: Those who assist completion of the task.
:: Those who assist completion of the task. For small tasks, may be "—".


:; ''Consulted''
:; ''Consulted''
Line 20: Line 24:
:: Those who are kept up-to-date on progress; and with whom there is one-way communication.
:: Those who are kept up-to-date on progress; and with whom there is one-way communication.


== Table ==
== Task Table ==
{{admon/note|This an early cut. Please feel free to add new tasks as appropriate — just let one of the coordinators know.}}
{{admon/warning|''Kanban!''|We'll keep the main tasks here, but the subtasks will probably be replaced with a Kanban board on our [http://taiga.cloud.fedoraproject.org/project/two-week-atomic/kanban taiga site]}}


{|
{|
Line 40: Line 46:
|-
|-
! scope="row" colspan="2" | <!-- task      -->Update koji for nightly image builds  
! scope="row" colspan="2" | <!-- task      -->Update koji for nightly image builds  
| <!-- responsible-->
| <!-- responsible-->ausil
| <!-- assists    -->
| <!-- assists    -->maxamillion
| <!-- consulted  -->
| <!-- consulted  -->
| <!-- informed  -->
| <!-- informed  -->mattdm, jkurik
| <!-- status    -->0%
| <!-- status    -->100%
|-
|-
| <!-- task      -->
| <!-- task      -->
Line 51: Line 57:
| <!-- assists    -->
| <!-- assists    -->
| <!-- consulted  -->
| <!-- consulted  -->
| <!-- informed  -->
| <!-- informed  -->mattdm
| <!-- status    -->?
| <!-- status    -->100%
|-
|-
| <!-- task      -->
| <!-- task      -->
Line 59: Line 65:
| <!-- assists    -->
| <!-- assists    -->
| <!-- consulted  -->
| <!-- consulted  -->
| <!-- informed  -->
| <!-- informed  -->"
| <!-- status    -->0%
| <!-- status    -->100%
|-
|-
| <!-- task      -->
| <!-- task      -->
Line 67: Line 73:
| <!-- assists    -->
| <!-- assists    -->
| <!-- consulted  -->
| <!-- consulted  -->
| <!-- informed  -->
| <!-- informed  -->"
| <!-- status    -->DROPPED
|-
| <!-- task      -->
| <!-- subtask    -->trigger on compose rather than on a timer (non-blocker)
| <!-- responsible-->
| <!-- assists    -->
| <!-- consulted  -->
| <!-- informed  -->"
| <!-- status    -->0%
| <!-- status    -->0%
|-
|-
! scope="row" colspan="2" | <!-- task      -->Create automated test system
| <!-- task      -->
| <!-- subtask    -->only build if contents change (non-blocker)
| <!-- responsible-->
| <!-- responsible-->
| <!-- assists    -->
| <!-- assists    -->
| <!-- consulted  -->
| <!-- consulted  -->
| <!-- informed  -->
| <!-- informed  -->"
| <!-- status    -->0%
| <!-- status    -->0%
|-
! scope="row" colspan="2" | <!-- task      -->Create automated test system
| <!-- responsible-->kushal
| <!-- assists    -->
| <!-- consulted  -->
| <!-- informed  -->QA, mattdm, jkurik
| <!-- status    -->100%
|-
|-
| <!-- task      -->
| <!-- task      -->
Line 82: Line 104:
| <!-- assists    -->
| <!-- assists    -->
| <!-- consulted  -->
| <!-- consulted  -->
| <!-- informed  -->
| <!-- informed  -->mattdm
| <!-- status    -->0%
| <!-- status    -->100%
|-
|-
| <!-- task      -->
| <!-- task      -->
Line 90: Line 112:
| <!-- assists    -->
| <!-- assists    -->
| <!-- consulted  -->
| <!-- consulted  -->
| <!-- informed  -->
| <!-- informed  -->"
| <!-- status    -->100%
|-
| <!-- task      -->
| <!-- subtask    -->basic smoketests functional (deeper testing desired, but out of scope here)
| <!-- responsible-->
| <!-- assists    -->jasonbrooks
| <!-- consulted  -->
| <!-- informed  -->mattdm, QA
| <!-- status    -->100%
|-
| <!-- task      -->
| <!-- subtask    -->ability to run non-gating advisory tests (optional)
| <!-- responsible-->
| <!-- assists    -->
| <!-- consulted  -->
| <!-- informed  -->mattdm
| <!-- status    -->0%
| <!-- status    -->0%
|-
|-
Line 98: Line 136:
| <!-- assists    -->
| <!-- assists    -->
| <!-- consulted  -->
| <!-- consulted  -->
| <!-- informed  -->
| <!-- informed  -->"
| <!-- status    -->0%
| <!-- status    -->100%
|-
|-
| <!-- task      -->
| <!-- task      -->
Line 106: Line 144:
| <!-- assists    -->
| <!-- assists    -->
| <!-- consulted  -->
| <!-- consulted  -->
| <!-- informed  -->
| <!-- informed  -->"
| <!-- status    -->100%
|-
| <!-- task      -->
| <!-- subtask    -->mechanism to mark a build as bad even if automatic tests pass
| <!-- responsible-->
| <!-- assists    -->
| <!-- consulted  -->
| <!-- informed  -->"
| <!-- status    -->100%
|-
| <!-- task      -->
| <!-- subtask    -->migrate to taskotron instead of tunir, when tasktron is ready (non-blocker)
| <!-- responsible-->
| <!-- assists    -->
| <!-- consulted  -->
| <!-- informed  -->"
| <!-- status    --> (Not ready / dropped)
|-
! scope="row" colspan="2" | <!-- task      -->Create automatic bug management system
| <!-- responsible-->
| <!-- assists    -->
| <!-- consulted  -->
| <!-- informed  -->mattdm, jkurik
| <!-- status    -->0%
| <!-- status    -->0%
|-
|-
| <!-- task      -->
| <!-- task      -->
| <!-- subtask    -->auto-file ticket or bug if test fails or no image found (update existing ticket if not first failure)
| <!-- subtask    -->file bugs for build, test, or release failure  
| <!-- responsible-->
| <!-- responsible-->
| <!-- assists    -->
| <!-- assists    -->
| <!-- consulted  -->
| <!-- consulted  -->
| <!-- informed  -->
| <!-- informed  -->"
| <!-- status    -->0%
| <!-- status    -->0%
|-
|-
| <!-- task      -->
| <!-- task      -->
| <!-- subtask    -->mechanism to mark a build as bad even if automatic tests pass
| <!-- subtask    -->on subsequent failures, update bugs with comments
| <!-- responsible-->
| <!-- responsible-->
| <!-- assists    -->
| <!-- assists    -->
| <!-- consulted  -->
| <!-- consulted  -->
| <!-- informed  -->
| <!-- informed  -->"
| <!-- status    -->0%
| <!-- status    -->0%
|-
|-
| <!-- task      -->
| <!-- task      -->
| <!-- subtask    -->mechanism to mark a build as bad even if automatic tests pass
| <!-- subtask    -->on success, close bugs
| <!-- responsible-->
| <!-- responsible-->
| <!-- assists    -->
| <!-- assists    -->
| <!-- consulted  -->
| <!-- consulted  -->
| <!-- informed  -->
| <!-- informed  -->"
| <!-- status    -->0%
| <!-- status    -->0%
|-
|-
! scope="row" colspan="2" | <!-- task      -->Create automatic release system  
! scope="row" colspan="2" | <!-- task      -->Create automatic release system  
| <!-- responsible-->
| <!-- responsible-->maxamillion
| <!-- assists    -->
| <!-- assists    -->
| <!-- consulted  -->
| <!-- consulted  -->
| <!-- informed  -->
| <!-- informed  -->mattdm, jkurik
| <!-- status    -->0%
| <!-- status    -->80%
|-
|-
| <!-- task      -->
| <!-- task      -->
Line 145: Line 206:
| <!-- assists    -->
| <!-- assists    -->
| <!-- consulted  -->
| <!-- consulted  -->
| <!-- informed  -->
| <!-- informed  -->"
| <!-- status    -->0%
| <!-- status    -->75%
|-
|-
| <!-- task      -->
| <!-- task      -->
Line 153: Line 214:
| <!-- assists    -->
| <!-- assists    -->
| <!-- consulted  -->
| <!-- consulted  -->
| <!-- informed  -->
| <!-- informed  -->"
| <!-- status    -->0%
| <!-- status    -->100%
|-
|-
| <!-- task      -->
| <!-- task      -->
Line 161: Line 222:
| <!-- assists    -->
| <!-- assists    -->
| <!-- consulted  -->
| <!-- consulted  -->
| <!-- informed  -->
| <!-- informed  -->"
| <!-- status    -->0%
| <!-- status    -->100%
|-
|-
| <!-- task      -->
| <!-- task      -->
Line 169: Line 230:
| <!-- assists    -->
| <!-- assists    -->
| <!-- consulted  -->
| <!-- consulted  -->
| <!-- informed  -->
| <!-- informed  -->"
| <!-- status    -->0%
| <!-- status    -->50%
|-
|-
| <!-- task      -->
| <!-- task      -->
| <!-- subtask    -->email announcement
| <!-- subtask    -->email announcement
| <!-- responsible-->
| <!-- responsible-->
| <!-- assists    -->
| <!-- assists    -->jzb
| <!-- consulted  -->
| <!-- consulted  -->
| <!-- informed  -->
| <!-- informed  -->"
| <!-- status    -->0%
| <!-- status    -->100%
|-
|-
| <!-- task      -->
| <!-- task      -->
Line 185: Line 246:
| <!-- assists    -->
| <!-- assists    -->
| <!-- consulted  -->
| <!-- consulted  -->
| <!-- informed  -->
| <!-- informed  -->"
| <!-- status    -->0%
| <!-- status    -->50%
|-
|-
! scope="row" colspan="2" | <!-- task      -->Create new website
! scope="row" colspan="2" | <!-- task      -->Create new website
| <!-- responsible-->
| <!-- responsible-->
| <!-- assists    -->
| <!-- assists    -->jzb
| <!-- consulted  -->
| <!-- consulted  -->
| <!-- informed  -->
| <!-- informed  -->mattdm, jkurik
| <!-- status    -->0%
| <!-- status    -->0%
|-
|-
| <!-- task      -->
| <!-- task      -->
| <!-- subtask    -->decide on location (stand alone, still part of getfedora.org, or labs.fpo)  
| <!-- subtask    -->decide on location (stand alone, still part of getfedora.org, or labs.fpo)  
| <!-- responsible-->jzb
| <!-- assists    -->
| <!-- consulted  -->Cloud WG, Design Team, Websites
| <!-- informed  -->mattdm
| <!-- status    -->0%
|-
| <!-- task      -->
| <!-- subtask    -->site design
| <!-- responsible-->
| <!-- responsible-->
| <!-- assists    -->
| <!-- assists    -->
| <!-- consulted  -->jzb
| <!-- informed  -->
| <!-- status    -->0%
|-
| <!-- task      -->
| <!-- subtask    -->new copy (introduction, documentation, disclaimers)
| <!-- responsible-->jzb
| <!-- assists    -->jasonbrooks
| <!-- consulted  -->
| <!-- consulted  -->
| <!-- informed  -->
| <!-- informed  -->
Line 204: Line 281:
|-
|-
| <!-- task      -->
| <!-- task      -->
| <!-- subtask    -->site design
| <!-- subtask    -->new artwork
| <!-- responsible-->
| <!-- responsible-->
| <!-- assists    -->
| <!-- assists    -->
| <!-- consulted  -->
| <!-- consulted  -->jzb
| <!-- informed  -->
| <!-- informed  -->
| <!-- status    -->0%
| <!-- status    -->0%
Line 215: Line 292:
| <!-- responsible-->
| <!-- responsible-->
| <!-- assists    -->
| <!-- assists    -->
| <!-- consulted  -->
| <!-- informed  -->jzb
| <!-- status    -->0%
|-
| <!-- task      -->
| <!-- subtask    -->changes to getfedora.org as/if appropriate (crosslinks, etc.)
| <!-- responsible-->
| <!-- assists    -->jzb
| <!-- consulted  -->
| <!-- consulted  -->
| <!-- informed  -->
| <!-- informed  -->
| <!-- status    -->0%
| <!-- status    -->0%
|-
! scope="row" colspan="2" | <!-- task      -->Trademark approval
| <!-- responsible-->mattdm
| <!-- assists    -->—
| <!-- consulted  -->Council, jzb
| <!-- informed  -->Other change owners, jkurik
| <!-- status    -->100%
|-
| <!-- task      -->
| <!-- subtask    -->for use of Fedora Atomic Host
| <!-- responsible-->mattdm
| <!-- assists    -->—
| <!-- consulted  -->Council
| <!-- informed  -->Other change owners
| <!-- status    -->100%
|-
| <!-- task      -->
| <!-- subtask    -->possibly for new artwork (optional)
| <!-- responsible-->mattdm
| <!-- assists    -->—
| <!-- consulted  -->Design, Council
| <!-- informed  -->Other change owners, Websites
| <!-- status    -->(not yet required)
|-
! scope="row" colspan="2" | <!-- task      -->Overall communication and coordination
| <!-- responsible-->mattdm
| <!-- assists    -->jzb
| <!-- consulted  -->Cloud SIG, upstream Project Atomic, Release Engineering, Websites, Design
| <!-- informed  -->FESCo, jkurik
| <!-- status    -->10%
|-
|-
|}
|}
== Glossary of Nicknames ==
* ausil [[User:Ausil|Dennis Gilmore]]
* jkurik [[User:Jkurik|Jan Kuřík]]
* jzb [[User:Jzb| Joe Brockmeier]]
* kushal [[User:Kushal|Kushal Das]]
* mattdm [[User:mattdm| Matthew Miller]]
* maxamillion [[User:Maxamillion| Adam Miller]]
* walters [[User:Walters| Colin Walters]]
== Various Task Notes ==
* If we get to the point of only building images when there are changes to the content set, that process still needs to notify the testing process that no build was generated ''on purpose'' rather than due to failure, and that then trickles down to the automatic release process in the (unlikely, but theoretical) possibility that nothing changes in the content set for two whole weeks.
* I'm imaging the "manual override" to be a command that authorized users can run to put a message on the fedmsg bus declaring a certain build to be bad (or possibly good), and this would override any automatic test results for an image with a matching name. (Possibly only automatic test results with an earlier timestamp? [[User:Mattdm|Mattdm]] ([[User talk:Mattdm|talk]]) 23:21, 18 June 2015 (UTC)
** this same mechanism could also be used to label certain images as special in some other way (for example, for non-atomic images, to mark certain nightly builds as RCs or gold composes) [[User:Mattdm|Mattdm]] ([[User talk:Mattdm|talk]]) 23:21, 18 June 2015 (UTC)
* Assuming the bug tracking system here is Bugzilla, we'll need Bugzilla actually set up for this. That means either setting up a new Component for each image type we create in the main Fedora bugzilla product, or creating a new bugzilla product. That could be "Fedora Atomic", but it might be better for it to be "Fedora Images" (keeping the main product's components mostly corresponding to RPMs).
== Schematic ==
[[File:TwoWeekAtomic-Overview-v2.png]]

Latest revision as of 15:27, 25 September 2015

Responsibility Matrix for the Two Week Atomic Fedora Change

This is a RACI matrix for tasks required to implement Two Week Atomic. Work is tracked in Taiga: http://taiga.cloud.fedoraproject.org/project/acarter-fedora-docker-atomic-tooling/wiki/home

Is this current?

It is, as of 2015-09-25.

Definitions

Here, we're using what Wikipedia calls "RACI (alternative scheme)":


Responsible
The person responsible for the performance of the task. There should be exactly one person with this assignment for each task. People in the Assists column for the overall task may be Responsible for subtasks, but it's the top-level Responsible person's job to make sure those subtasks do not get blocked.
Assists
Those who assist completion of the task. For small tasks, may be "—".
Consulted
Those whose opinions are sought; and with whom there is two-way communication.
Informed
Those who are kept up-to-date on progress; and with whom there is one-way communication.

Task Table

Note.png
This an early cut. Please feel free to add new tasks as appropriate — just let one of the coordinators know.
Warning.png
Kanban!
We'll keep the main tasks here, but the subtasks will probably be replaced with a Kanban board on our taiga site
Task Subtask Responsible Assists Consulted Informed Current Status
Update koji for nightly image builds ausil maxamillion mattdm, jkurik 100%
script run from cron nightly mattdm 100%
update script for installer iso " 100%
better implementation with pungi4 (non-blocker) " DROPPED
trigger on compose rather than on a timer (non-blocker) " 0%
only build if contents change (non-blocker) " 0%
Create automated test system kushal QA, mattdm, jkurik 100%
listener for successful builds mattdm 100%
automatic test execution " 100%
basic smoketests functional (deeper testing desired, but out of scope here) jasonbrooks mattdm, QA 100%
ability to run non-gating advisory tests (optional) mattdm 0%
results to fedmsg " 100%
results dashboard " 100%
mechanism to mark a build as bad even if automatic tests pass " 100%
migrate to taskotron instead of tunir, when tasktron is ready (non-blocker) " (Not ready / dropped)
Create automatic bug management system mattdm, jkurik 0%
file bugs for build, test, or release failure " 0%
on subsequent failures, update bugs with comments " 0%
on success, close bugs " 0%
Create automatic release system maxamillion mattdm, jkurik 80%
every two weeks, scan for images which pass all tests " 75%
integration with fedimg " 100%
upload to alt.fpo (or main mirrors?) " 100%
automatically update website " 50%
email announcement jzb " 100%
fallback mechanism for no builds in two weeks " 50%
Create new website jzb mattdm, jkurik 0%
decide on location (stand alone, still part of getfedora.org, or labs.fpo) jzb Cloud WG, Design Team, Websites mattdm 0%
site design jzb 0%
new copy (introduction, documentation, disclaimers) jzb jasonbrooks 0%
new artwork jzb 0%
site implementation jzb 0%
changes to getfedora.org as/if appropriate (crosslinks, etc.) jzb 0%
Trademark approval mattdm — Council, jzb Other change owners, jkurik 100%
for use of Fedora Atomic Host mattdm — Council Other change owners 100%
possibly for new artwork (optional) mattdm — Design, Council Other change owners, Websites (not yet required)
Overall communication and coordination mattdm jzb Cloud SIG, upstream Project Atomic, Release Engineering, Websites, Design FESCo, jkurik 10%

Glossary of Nicknames

Various Task Notes

  • If we get to the point of only building images when there are changes to the content set, that process still needs to notify the testing process that no build was generated on purpose rather than due to failure, and that then trickles down to the automatic release process in the (unlikely, but theoretical) possibility that nothing changes in the content set for two whole weeks.
  • I'm imaging the "manual override" to be a command that authorized users can run to put a message on the fedmsg bus declaring a certain build to be bad (or possibly good), and this would override any automatic test results for an image with a matching name. (Possibly only automatic test results with an earlier timestamp? Mattdm (talk) 23:21, 18 June 2015 (UTC)
    • this same mechanism could also be used to label certain images as special in some other way (for example, for non-atomic images, to mark certain nightly builds as RCs or gold composes) Mattdm (talk) 23:21, 18 June 2015 (UTC)
  • Assuming the bug tracking system here is Bugzilla, we'll need Bugzilla actually set up for this. That means either setting up a new Component for each image type we create in the main Fedora bugzilla product, or creating a new bugzilla product. That could be "Fedora Atomic", but it might be better for it to be "Fedora Images" (keeping the main product's components mostly corresponding to RPMs).

Schematic

TwoWeekAtomic-Overview-v2.png

Retrieved from "https://fedoraproject.org/w/index.php?title=Changes/Two_Week_Atomic/RACI&oldid=423094"