As a result from the WhenIsGood I sent out[0], the meeting to discuss Fedora Projects Tooling has been set for 2015-05-13 at 14:00 UTC https://apps.fedoraproject.org/calendar/infrastructure/2015/5/13/?tzone=U... Hope to see everyone there!

We set up http://taiga.cloud.fedoraproject.org with:

On Fri, Jun 26, 2015 at 04:17:40PM -0400, Ralph Bean wrote: > We set up http://taiga.cloud.fedoraproject.org with: Oh, cool. So I went ahead and made this. I had previously put a bunch of imagined subtasks on the wiki, and instead I put those here, and will probably change the wiki to just show the very high level. So: <http://taiga.cloud.fedoraproject.org/project/two-week-atomic/kanban> I set this up as a Kanban project, with six top-level tasks and a bunch of subtasks. However, I'm not sure that's necessarily the best level for visibility here; it might actually be better to set up those six as individual projects so their individual subtasks can be more visibile. Particularly, I'm concerned about the "in progress" column here — these all might be too big for that. I *also* enabled the "scrum backlog" feature, which gives a different view on the same things: <http://taiga.cloud.fedoraproject.org/project/two-week-atomic/backlog> and which also kind of makes me want to have more granularity. But, again, I dunno. That might be too much. Also that wants us to configure sprints and stuff, which is a whole commitment-to-approach. We might want

-- Matthew Miller <mattdm(a)fedoraproject.org&gt; Fedora Project Leader

On Fri, Jun 26, 2015 at 09:50:58PM -0400, Matthew Miller wrote: > <http://taiga.cloud.fedoraproject.org/project/two-week-atomic/backlog> > and which also kind of makes me want to have more granularity. But, > again, I dunno. That might be too much. Also that wants us to configure > sprints and stuff, which is a whole commitment-to-approach. Okay, so, just to see how it looks, I broke this down into four (4!) sub-projects in Taiga. I kind of wish the system supported Epics (see upstream thoughts on that <https://blog.taiga.io/epic-stories.html>), but it doesn't. So, it looks like this: http://taiga.cloud.fedoraproject.org/project/two-week-atomic-build-sys/ka... http://taiga.cloud.fedoraproject.org/project/two-week-atomic-test-sys/kanban http://taiga.cloud.fedoraproject.org/project/two-week-atomic-rel-sys/kanban http://taiga.cloud.fedoraproject.org/project/two-week-atomic-websites/kanban with each project basically corresponding to one of the big blocks from <https://fedoraproject.org/wiki/Changes/Two_Week_Atomic#Schematic>;. What do you all think? Is this better or worse than everything in one project for task tracking? OR, do we want to do this entirely differently, with one "release engineering" project and all releng tasks for all of everything (whether Fedora Changes, internal projects, technical debt, etc.)?

-- Matthew Miller <mattdm(a)fedoraproject.org&gt; Fedora Project Leader _______________________________________________ rel-eng mailing list rel-eng(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/rel-eng

On Mon, Jun 29, 2015 at 12:11:16PM -0500, Adam Miller wrote: > > OR, do we want to do this entirely differently, with one "release > > engineering" project and all releng tasks for all of everything > This would be my preference but I'm not sure if everyone would agree. > On my old team we would use "tags" to define if a card belongs to a > project and just prepend it to the title of the card. So something > like "[TwoWeekAtomic] Task 1" for example, and then there would be a > project card with an explanation of the project and a list of tasks > (with links to cards associated with tasks). That would allow us to > quickly see project status and track related tasks on the board. > Just a suggestion. I'm open to alternatives though. I wish we could have both views at once. I think the "all work on one wall" approach works well for a single team dedicated to that work, but I'm not sure how to track something like this with it. A) There's plenty of work that will be not relevant to someone invested in this change but not releng overall. I don't see an easy way in Taiga to filter the Kanban board by tags, making hard to see the state of _this_ project. B) On the other side, there's plenty of work in this project that isn't release engineering. Where does that work get tracked? Say, for example, someone from Websites, or perhaps (wholly theoretically) a UX designer from Atomic who is making a first contribution to Fedora through this project — where does their work get tracked? If the filtering were better (and perhaps I'm just missing something) we could solve B by declaring that we're going to track the change as a Rel-Eng project, and that everyone involved should see themselves through that lens. For these two changes (Two-Week Atomic, Layered Images) that might just be okay — perhaps even with the lack of filtering. But does it scale to _all_ of the Changes?

-- Matthew Miller <mattdm(a)fedoraproject.org&gt; Fedora Project Leader

We set up http://taiga.cloud.fedoraproject.org [but]... .. <snip> .. It doesn't currently have backups in place. I've been meaning to do it but I just haven't had/made time. I'll respond to this thread when it's finally done. (we have scripts to manage postgres backups like this already, so it should be easy).

On Fri, May 08, 2015 at 08:59:49AM -0500, Adam Miller wrote: > As a result from the WhenIsGood I sent out[0], the meeting to > discuss Fedora Projects Tooling has been set for 2015-05-13 at 14:00 > UTC > https://apps.fedoraproject.org/calendar/infrastructure/2015/5/13/?tzone=U... > Hope to see everyone there! Okay, so, what are our next steps here? As I remember the meeting :) there was a lot of support for taiga.io, but we wanted to hold off actually going through the process of packaging it until actually trying it. I'd like to suggest that we use the hosted taiga.io service for organizing work on <https://fedoraproject.org/wiki/Changes/Two_Week_Atomic> <https://fedoraproject.org/wiki/Changes/Layered_Docker_Image_Build_Service... Adam mentioned that Ralph has a fedauth plugin, and maybe we could even get them to add that as a sign-in option on the hosted service (right next to "Login with github") — but I suggest just individual accounts until Flock. Adam's other concern was backups — what do we do if the hosted service folds? I see that there _is_ export/import functionality, and possibly that's scriptable, but we could at least do it manually weekly for the summer (and accept a little bit of risk). What do you all think?

-- Matthew Miller <mattdm(a)fedoraproject.org&gt; Fedora Project Leader