I was just experimenting with a new project board for a somewhat involved issue/enhancement. https://github.com/apache/accumulo/projects/2
Typically we just create one issue that would spawn multiple issues. Back in JIRA this was OK but would get confusing jumping around between all the tickets and trying to make sense of what depends on what using the "link" feature. We haven't had a good way to do that with GitHub Issues so I like this idea. The little bit that I have used the project boards was very pleasant. On Fri, Jun 14, 2019 at 12:30 PM Christopher <[email protected]> wrote: > Accumulo Devs, > > I've started to play around with the GitHub per-repository project > boards for organizing/planning some issues for 2.1.0. > > https://help.github.com/en/articles/about-project-boards > > I propose we use them instead of labels to track the targeted "fix > version" for our various versions. > > Advantages: > > 1. An issue can be assigned to more than one project board to support > targeting an issue for multiple versions. This was the main reason we > didn't want to use milestones. The limitation for milestones is that > you can only have one milestone per issue. However, a milestone is > just a simple project board with only two states: open and closed. We > can effectively get multiple milestones by using project boards > directly. > 2. Projects can be "closed", meaning that once we release, we don't > have them cluttering the GitHub issue tracker UI, in the drop-down > menus. This is one of the biggest problems with one-label per release > version: it doesn't scale well. Since we can close a project board > once it is released (can also be re-opened), we can much more sanely > track releases, and limit our use of labels to things like priority, > question vs. bug vs. feature request (you know, a relatively small > static set of well-defined labels). > 3. Project boards have multiple states. We can track "To do" vs. "In > progress" vs. "Done" for each version. > 4. Built-in automation: rather than a simple open/closed, like > milestones, project boards can automatically move things to "In > progress" when a pull request is opened, for example, or move it from > "Done" to "In progress" if an issue is re-opened. This isn't critical, > but it's a nice feature. > 5. Manually marking issues as "In progress" is as simple as > drag-and-drop. So, we don't duplicate effort, if somebody (say, a > contributor who can't be "assigned" an issue on GitHub) wants to work > on an issue, we can move it to "In progress" so it's easy to see that > somebody else is currently working on it. > > Disadvantages: > > 1. You can still search issues by project, but not by project name, > only project ID. This is slightly inconvenient when manually typing in > search criteria. It's not difficult to find the project ID (it's in > the URL when you click on the project in the UI): > > https://help.github.com/en/articles/searching-issues-and-pull-requests#search-by-project-board > 2. When searching issues in GitHub, you can filter by project board in > the UI by selecting from the drop-down. However, it only shows the > open boards, not the closed ones, in that UI. (Closed ones are still > searchable manually.) > 3. When viewing issue search results, the projects an issue are > associated with (and their state) is not viewable in the search > results... you have to open each issue to see that, or to use a > filter, or click on the project board. This is less convenient than > labels and milestones for identifying associated project boards for an > issue at a mere glance. > 4. Project boards aren't color-coded, like labels. > > In my view, the advantages significantly outweigh the disadvantages, > and get us close to what we wanted (multiple milestones) when we first > started using GitHub as our issue tracker. > > If folks are on board with using project boards for tracking issues > for a release, I'm willing to do all the tedious work of converting > our labels over to project boards, and updating any relevant developer > docs. > > Please consider this proposal. I think it's a big improvement to our > workflows, and I'm willing to do all the work. > > Thanks for your consideration, > > Christopher >
