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?