On Wed, Jan 11, 2017 at 10:05 PM, Dusty Mabe <dusty@xxxxxxxxxxxxx> wrote: > > > On 01/11/2017 05:50 PM, Adam Miller wrote: >> Hello all, >> Recently I attempted to start a mailing list thread that was the >> product of a discussion on IRC about putting together an Atomic WG >> workshop session[0] at DevConf[1]. >> >> This was then discussed during today's Atomic WG Meeting[2] where it >> was decided that we should make this Workshop into a re-occurring >> Virtual Fedora Activity Day(FAD[3]) instead taking place every 2 >> months. >> >> I would like to propose the following: >> Each Virtual FAD occurs on a Thursday, the day after a Fedora >> Atomic WG meeting such that we can use the meeting the day before to >> plan out the work to be done at the Virtual FAD. All work will be >> tracked in a kanban[4] board, I've created one for this purpose in >> Fedora's Taiga instance[5] (Note: I don't know why my FAS name is in >> the URL, Taiga just does that). >> In the kanban board, we would create cards in the NEW column >> through out the two month cycle between Virtual FADs (these should >> correlate to tickets in pagure[6]), then on the meeting before the FAD >> we would "groom" the NEW cards that we want to accomplish on the >> following day of the Virtual FAD, these "groomed" cards would be >> placed into the READY column to signify they are ready to be worked >> on. On the day of the VFAD, participants/contributors would then >> assign a card to themselves that they want to work on, and move the >> card into "IN PROGRESS" so that everyone knows what is being worked on >> and nobody attempts to work on the same thing (unless that's >> intentional, in that case both people's names should be listed in the >> card description for reference). Once a task is done, then it should >> be moved to the DONE column. This will give a good reflection of what >> work was accomplished during the VFAD and we can (optionally) have a >> retrospective meeting after the VFAD about what went well, what didn't >> go well, and what we could do better next time. Also the day before >> the next VFAD at the start of the "grooming" session (the weekly >> Atomic WG meeting), all the previous VFAD's cards in the DONE column >> from the previous VFAD should be moved to ARCHIVED for posterity. > > This sounds good but I'm not sure I'm ready to have work items broken > out into another place. Could we get something close by using labels > on issues in pagure? Really what I'm trying to do here is prevent > extra overhead and also prevent duplicated information where there is > a question of what is right and what is wrong? > Not to the best of my knowledge. Pagure doesn't have a feature that is similar to a kanban board and I don't know of a way to structure the labels that would really make the work track-able using them. If we can generate a report view of the labels, maybe it would work but then we'd end up with a lot of tickets and cross-linking tickets to correlate small units of work with the original ticket. (Which might be fine, but I thought I'd point that out as a concern). There is the Roadmap view in Pagure (example[0]) and we could potentially come up with a convention around that. In my original proposal, I was thinking that tickets would be the similar to an "Epic" such that small tasks that roll up under a more broad statement of work would exist in Taiga (we could even make a Tagia label for each ticket and label cards accordingly for easy filter/reporting) and the broad statement of work (epic) would live in Taiga. I probably didn't articulate this well. My desire to use Taiga for this is not at all a slight at Pagure, it's a fine tool, but we're moving into the space of Project Management and out of the space of Git Forge which Pagure just isn't currently targeting for the former with it's feature set. However, if Pagure was to add a kanban-style view/UX similar to GitHub Projects[1] then I wouldn't consider suggesting Taiga and if we were to go the route of the initial proposal (or even sort out a way to make pagure lables/milestones work), we could certainly transition in the future. >> >> Cards created should be units of work that can feasibly be >> accomplished in a day or less worth of work. >> >> I would like to ultimately propose we move to a more iterative cycle >> where we use this workflow weekly instead of dedicating a single day >> every 2 months (these periods of time are often known as a "sprint" in >> Agile[7]) but my hope is that this is a good place to start and we can >> improve over time. >> >> If this is acceptable as a change we would like to adopt as a group, I >> am happy to pre-populate the kanban board with work items we had >> previously discussed that we wanted to accomplish as the original >> agenda to the (now defunct) DevConf Workshop. From there I would >> propose that the first meeting after DevConf (2017-02-01) be used as >> the first grooming session and the following Thursday be the first >> VFAD (2017-02-02). From there we would set a schedule for every 2 >> months to have a VFAD. > > Sounds good. As a note we may still want to meet around devconf but > just not work on anything that we need the entire WG for. +1 -AdamM [0] - https://pagure.io/pungi/roadmap [1] - https://help.github.com/articles/about-projects/ > >> >> If everyone is in agreement, I'll also get a section of the Wiki page >> (which we need to move out of the Cloud namespace) added to document >> this workflow for newcomers who would like to join the Atomic WG. >> >> Thank you, >> -AdamM >> >> >> [0] - https://lists.fedoraproject.org/archives/list/cloud@xxxxxxxxxxxxxxxxxxxxxxx/thread/WBTWBLOYWG66EDXJO2I4G3XY3X6EFAIF/ >> [1] - https://devconf.cz/index.html >> [2] - https://lists.fedoraproject.org/archives/list/cloud@xxxxxxxxxxxxxxxxxxxxxxx/thread/36EBX5WS36OSO57GDWBJVIU6CXRXT237/ >> [3] - https://fedoraproject.org/wiki/Fedora_Activity_Day_-_FAD >> [4] - https://en.wikipedia.org/wiki/Kanban >> [5] - https://taiga.fedorainfracloud.org/project/maxamillion-fedora-atomic-wg/kanban >> [6] - https://pagure.io/atomic-wg/issues >> [7] - https://en.wikipedia.org/wiki/Agile_software_development >> _______________________________________________ >> cloud mailing list -- cloud@xxxxxxxxxxxxxxxxxxxxxxx >> To unsubscribe send an email to cloud-leave@xxxxxxxxxxxxxxxxxxxxxxx >> > _______________________________________________ > cloud mailing list -- cloud@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to cloud-leave@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ cloud mailing list -- cloud@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to cloud-leave@xxxxxxxxxxxxxxxxxxxxxxx
