Hi all, Some news on the phabricator setup for Plasma Mobile. We want to use phabricator here to track tasks, designs and patch review.
Task tracking Phabricator has so-called Workboards, these are kanban-style board which can contain tasks. The board has 4 columns, and tasks move from left to right during completion. I've set up the following lanes (which is in line with how we've been using Kanban board in Plasma for some time, it's a bit "waterfalley", but I think with some added agility, these would work fine. The columns (or stages) are: - Todo: A task is open and not has already being worked on - Design: A feature has been designed, but not implemented yet - Implementation: An existing design is being implemented - Review: A feature has been developed, but is not fully integrated and shipped in the dev version - A feature is done and integrated in the development version of the reference OS image Of course, there's some overlap between especially the design and implementation stages, but I think it's a good way to get ourselves more into design-driven development. Especially the last stages mean that we do not just want some commits to have happened, but that we verify that a feature is available and functional in the reference image. (This last step is something we traditionally often forget, as the OS integration bit is usually in the hand of a Linux Distro team.) The stages may differ a bit for different workboard, see Plasma Docs board for example doesn't have a design stage, there it's "todo", "writing", "review" and "done" -- it makes more sense in this context. A specific task can belong to one or more projects. One such project is Plasma Mobile (rather generic). Then, there is a number of "sub projects" which can contain more detailed tasks. This two-level setup allows us to also get a complete picture of sub-tasks such as more complex design tasks (the HIG would be a good example here) or things as documentation (which also is something we need to handle in a more structured way). Tasks can have sub-tasks and blockers (tasks that need to be done before this one can be tackled). I haven't completely figured out which roles these would play, but I guess that's something we can find out once we're getting a bit more used to it. Therefore, it's good to reflect on the usage and that we all think about how we can use this tool more effectively. One idea that this feature may be very useful for is the scenario of a big task. In different stages, the task can change the project, so for example, in its design phase, it would belong to "Plasma Mobile" (PM) and "Plasma Design", while in a later phase, it could belong to "Plasma Mobile" and a "Plasma CI" (I just made this up), so during the "lifecycle" of the task, it moves across multiple workboards, and becomes visible to different people. My first feeling is that tasks that are very detailed should probably be only in the subprojects, bigger tasks that are also meaningful in a general context should also be under the Plasma Mobile project, but as I said, we may want to refine that. For now, I've set up the following Plasma "subprojects" (which each have their own work board): Plasma Mobile - tracks general progress on the mobile UI and implementation https://phabricator.kde.org/project/board/28/ Plasma Docs - tracks progress and of documenting everything https://phabricator.kde.org/project/board/31/ Plasma Design - tracks design tasks https://phabricator.kde.org/project/board/32/ Plasma Mobile SDK - tracks tasks specific to the SDK https://phabricator.kde.org/project/board/30/ I've started adding features that we have discussed in the past weeks, please feel free to amend the workboard with items you may have on your list. I will look into the code review functionality next. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel