Use of Projects Board?

[ann0see]

I've just enabled the Projects feature of GitHub. I hope this will help organizing and priorizing issues/bugs/...

[gilgongo]

Only just noticed this...! I think we need some form of Epic/Story relationship for some of the UI stuff to prevent it all getting fragmented perhaps? Can we do that?

[gilgongo]

Can I ask what we're expecting to do with Projects?

We don't yet have workflow involving things like testers or legal compliance, so I'm not sure what Projects are being used for other than indicating that something is being worked on (to-do, in progress, done). But that's effectively the same as marking them for a milestone (AKA release).

I can't immediately think of any reason to have them, and I'm a bit concerned their presence will be confusing. I'm inclined to suggest we remove them unless we can think of a good reason not to.

[gilgongo]

OK but it would be good to think through any benefits first.

Is the Project "Manage automation" function interesting? Eg if an Issue is opened, then it goes into "Triage", then once it's agreed on, it goes into "To Do", but can only go to "Done" once a PR on it has been approved etc.?

That might be useful in getting a better idea of when we can do a planned release, since the automation would tell us how close we are to that (so, "We just need to do those two new review requests on that PR").

But whether we'll ever be able to decide on the desired workflow for that is another matter :-) And it could get complex to maintain. Maybe one for the future?

Otherwise:

Grouping can be done with labels. But as I understand "Projects", they're essentially kanban boards, the purpose of which is to manage work though stages so that you don't have too much happening in one stage or with one person/group (so if the testers are stacked up but the designers have nothing to do, you can put some designers on another project ). This is why there is a number in the top left of each column - although GH doesn't have a "currency" feature that limits cards in each column as an "orthodox" kanban would. FOSS projects like ours mean that "resources" aren't really manageable in that sense though, so are those issues are a bit theoretical perhaps?

But right now, all we really need to know is "What could be worked on now? (so Issues, basically)", "What is going in for the next release, and maybe the one after? (so Milestones)" and maybe "Show me everything that relates to [thing]" where [thing] might be "UI", "bug", "documentation", etc (so Labels).

[hoffie]

Is the Project "Manage automation" function interesting? Eg if an Issue is opened, then it goes into "Triage", then once it's agreed on, it goes into "To Do", but can only go to "Done" once a PR on it has been approved etc.?

Yes, if the projects board were a bit more holistic (i.e. every open ticket is in some column), it would provide more benefit, I think.

That might be useful in getting a better idea of when we can do a planned release, since the automation would tell us how close we are to that (so, "We just need to do those two new review requests on that PR").

I'm not sure I'd use the projects board so much for release planning. Milestones work better for that, in my opinion. I'd use the projects board for a release-independent overview and maybe assigning milestones to specific issues as part of it.
I guess this is some separate discussion regarding release policy. In general I'd be in favor of "release early, release often", so, work on getting a new release out of the door as soon as it provides significant benefits (bugfixes, new features).

Grouping can be done with labels. But as I understand "Projects", they're essentially kanban boards, the purpose of which is to manage work though stages so that you don't have too much happening in one stage or with one person/group (so if the testers are stacked up but the designers have nothing to do, you can put some designers on another project ). This is why there is a number in the top left of each column - although GH doesn't have a "currency" feature that limits cards in each column as an "orthodox" kanban would. FOSS projects like ours mean that "resources" aren't really manageable in that sense though, so are those issues are a bit theoretical perhaps?

But right now, all we really need to know is "What could be worked on now? (so Issues, basically)", "What is going in for the next release, and maybe the one after? (so Milestones)" and maybe "Show me everything that relates to [thing]" where [thing] might be "UI", "bug", "documentation", etc (so Labels).

Yes, that fits my mental model as well. I see the Projects board as an opportunity to visualize the state of Issues.

I would gain the most value out of the following:

Needs triage	Backlog	In progress	Waiting on team	Waiting externally
Any new issue should be auto-moved here. We should focus on keeping this list down. Triage would involve checking if it is correct for this to be an issue and not a discussion, it should involve checking if this is a high priority issue such as a regression or a security problem. It should then be moved to the Backlog.	This is a potentially longer list of actionable issues we need to work on. Developers would grab them as they have time.	This is a list of issues which are already assigned and someone is working on them. This list should be kept small (Kanban-style).	On some issues, we need feedback from some or all team members. This column should be almost empty, so everyone of us should work on responding if needed.	Issues which can no longer worked on by us and need external feedback would be moved there. A common case would be bug reports where details (e.g. logs, traces) are missing.

• I don't see the value of a Closed column. While it might feel good to get things done, this column would just grow over time.
• I would avoid putting priorities into column names as well. I assume priorities can be visualized by moving issues up within their column (I don't see a native Priority attribute for issues though?). If we really need priorities there, I'd suggest some kind of Backlog-Fastlane, but I'd skip that if possible.

As far as I understand, Issues can be part of multiple Project boards. So my suggestion would not prevent anyone from keeping the existing or even adding new boards if necessary. Personally, I don't use or need them.

So, if we can agree to use the Project board similar to above, this would provide huge value (at least for myself ;)). I started tracking issues in my own Kanban-like text file which is... not optimal and which I would like to replace. :)

[gilgongo]

OK that makes sense I think. So the board looks at everything independently of Milestone, and if we need know if we can do a release we can just look at the milestone and if all issues/PRs on it are "Done" then we go for it (but see my comment about translation below).

So apart from the "Needs triage" column which would be automatic on creation of a new issue (or PR? is that supported?) to what extent are things progressed forward (or back) on the board by means other than dragging them there? So using the "Manage automation" feature which I see has things like PR review conditions and stuff.

I don't see the value of a Closed column.

I assume we'd still need a "done/closed" status though so we could know that we were ready for that release once all the issues/PRs in it were Done. Agree no need to show them in an ever-growing column though.

Issues can be part of multiple Project boards.

Not sure how that would work unless all boards had the same columns/rules though, but I can't think it through...

Also: Might translation fit into this? So would we have a column for translation tasks (app and website)? The reason is that translation has to be completed before a release can go out (well, on the app side at least) and may take a week or two.

[hoffie]

or PR? is that supported?

I think it would be valuable if we could handle PRs the same. I just checked and PRs are listed in the "Add cards" menu. The "Manage automation" menu also allows to make the same settings for PR as for issues.

to what extent are things progressed forward (or back) on the board by means other than dragging them there. So using the "Manage automation" feature which I see has things like PR review conditions and stuff.

Not sure if we even need that? If we see value in it, we could add a "In review" column. Not sure if the benefits outweight the additional screen space though.

I assume we'd still need a "done/closed" status though so we could know that we were ready for that release once all the issues/PRs in it were Done. Agree no need to show them in an ever-growing column though.

Wouldn't that require us to have release-specific boards or some other way to remove the done-in-a-previous-release issues?
I think Milestones would be a better way to get this overview.

Not sure how that would work unless all boards had the same columns/rules though, but I can't think it through...

Not sure if we need it at all. I just mentioned it because the Github UI makes me think that it is possible and maybe someone still wants to keep the existing boards. If they're unused, I'd be in favor of removing them.

[gilgongo]

Not sure if we even need that? If we see value in it, we could add a "In review" column.

Sorry, I don't follow. Not sure if we need what? The automation function?

Wouldn't that require us to have release-specific boards

I don't think so. I agree just having milestones would be fine. But without some way of saying "this is ready for the release it's tagged to" I don't know how we'd operate a release target.

If they're unused, I'd be in favor of removing them.

Yes, they are unused as far as I know. And I'm pretty sure you couldn't sanely have the same issue managed by different boards with different column names or workflow rules. Otherwise something "to do" on one that required approval to progress might be "needs triage" in another that doesn't or something, no?

[hoffie]

Sorry, I don't follow. Not sure if we need what? The automation function?

I thought you were looking for use cases for the automation functions. I could not come up with more than what you suggested.

But without some way of saying "this is ready for the release it's tagged to" I don't know how we'd operate a release target.

I would add the target milestone as soon as it becomes clear. If the issue is about a regression, it will be clear in the Needs triage stage already. If the issue is in the Backlog, it may not have a milestone yet. If it is In progress the amount of activity / closeness to being done would lead to the appropriate milestone being added.

I guess one important thing to be answered would be if every closed issue should have a milestone? I don't think we do that currently. It would have the benefit of making it possible to cross-check the changelog. For me, it would not be a requirement though.

If we wanted to go with the holistic approach of every issue having a milestone assigned, we could (auto?)assign the next milestone. When we get close to a release, we would move all issues/PRs which are not ready to be included to the next milestone. I'm not really sure if it's worth the hassle and if there would be any automation to do that...

[gilgongo]

@ann0see Sorry, I don't understand your points 1 and 2. Which Project wins if Issue X is (for example) "Done" in one Project board, but "Needing Approval" in another if that issue is being tracked for a release? (That is, to answer the question, "Do we have everything done for this release now?")

I realise that Projects aren't exclusively for tracking releases, but it's 90% of what we will I think be using them for.

[ann0see]

So let's think of two groups of people.
Group 1 = maintainers/main developers.
Group 2 = a group of people working on a sub project (e.g. the automatic build)

Group 1 needs to have an overview on a more general level. They'd use the board and workflow hoffie proposed.
Group 2 needs to have a detailed documentation on tasks. They'd use the e.g. the autobuild board. Once they're done, Group 1 needs to start reviewing (!=done) while Group 2 is already finished (=done). So both boards have different purposes. And different people who work on it.

I hope that's clearer now.

[gilgongo]

Once they're done, Group 1 needs to start reviewing (!=done) while Group 2 is already finished (=done)

OK so Group 2 would always finish working on tasks before Group 1 needed to start on them? So like a "pre-release" process? I think I see... But what is the question that Group 2 is using their project board to answer? Group 1's is "Can we release now?"

BTW also, if Group 2 closes a PR or an Issue, would Group 1 need to re-open it? Is that not sort of weird?

[ann0see]

But what is the question that Group 2 is using their project board to answer?

That's just for tracking the process of Group 2 internally. So nobody else would need to look at it (but can if he wants to).

if Group 2 closes a PR or an Issue, would Group 1 need to re-open it? Is that not sort of weird?

No. That wouldn't be the case:

Since only Group 1 has push access, they are the final ones who merge the PR and with this also the issue. I think the process I have in mind is not common since usually only one person works on a change, but it exists:

If we look at e.g. the french translation which we had a while ago, we'd have a typical example of group 2.

Definition:
@ann0see and you are in group 1.
French translators are in group 2.

I (= group 1) was annoyed with around 20 open PRs and at least I would have been happier if only one final PR had existed.

Group 2 would have benifited a lot if they had had a board. Group 1 wouldn't be interested in this. Only group 2 would use it to track their process so that confusions (which did occur as I remember) about which file already was translated could have been prevented. Of course, there are other ways to handle this (in one issue or discussion about translation, etc.) but having a board makes the process of them very visible.

[gilgongo]

That's just for tracking the process of Group 2 internally.

So as long as all the tasks for Group 2 happen before and therefore off the board of Group 1 then that's OK. I think. TBH I'm unsure.

@hoffie Can you comment on this multiple boards with issues tagged to releases thing? Does it affect your proposal?

[hoffie]

After some valuable discussion with @gilgongo, I think we were able to clear up lots of (all?) confusion. I'm trying to summarize:

• @gilgongo adds a new project board with the structure outlined above to the organization (called "Tracking").
• The existing (proof of concept) Main Project board within the jamulus code repo will be deleted. I will work on copying the existing assignments to the org-level version and will delete afterwards. Sadly, moving does not seem to be possible.
• @gilgongo's request to get an overview about all issues/PRs which are targeted for a specific release can be solved by adding the proper milestone to all relevant issues/PRs (we mostly do this already) and viewing the Main Project board with a milestone:"Release 3.7.0." filter.
• I now understand @gilgongo's fear of conflicting state in different boards and I fully agree with that regarding all of the existing boards as they share the same column layout. The (mostly) same visualization of the existing boards (e.g. autobuild, Windows installer, etc.) should be possible with the new Main Project board + filtering on specific labels. @gilgongo is therefore closing these boards as ok'ed by @ann0see.

The implications of adopting this pattern for all main developers are:

• Regularly open the project board and work on getting things triaged (i.e. to Backlog or closed if not a bug/feature).
• Move them the "In progress" if you start working on them.
• Move them to "Waiting externally" when we require feedback.
• Move them back to "In progress" when it's up to you to continue working on them.
• Move them to "Waiting internally" when feedback from other team members is required.
• Assign milestones to issues as they get ready (we do this already).

@jamulussoftware/maindevelopers If someone is opposed to doing that, please comment here. :)

[gilgongo]

BTW you can use labels if you want and just filter on those if you want to see what's going on with things relating to some other grouping.

Also: @nefarius2001 Can you close the autobuild project if that's OK? Thanks.

[gilgongo]

So this is my proposal for the "life cycle" for things to be in each state:

Triage
New Issue/PR? Automatically in Triage.
New Issue unclear? Was clear but now not? Move to Discussions (and off the board).
New PR not good? Use PR comments to discuss.

Backlog
New Issue all good? Manually move to Backlog (or In Progress if need be).
New PR all good? Automatically moves to Backlog with 3 approvals (or move manually, or to In Progress if need be)

In Progress
Backlog item assigned? In Progress.
Backlog Issue spawns PR? Link PR to Issue, remove any Milestone, close issue (and PR goes to Triage. Note: this would also apply to translations of both app and website). Issue automatically goes to Done.

• If while In Progress an item needs input from a team, or external, move there.
• If while In Progress an item is for release (assignee can decide), tag that. De-tag if looks like it won't make it.

Done
Once a PR is merged, automatically goes to Done.
Once all PRs linked to an Issue are merged/closed then the Issue is automatically moved to Done.

[gilgongo]

Hi @jamulussoftware/maindevelopers @jamulussoftware/translators @jamulussoftware/designers

Please read these:

#929 (reply in thread) (although we'll have a "Done" column)
#929 (comment)
#929 (reply in thread)

and post any comments/questions here by Sunday evening 7th April so we can write all this up properly, put it on the website and start implementing it.

[anprdev]