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
