Okay, so there doesn't seem to be any objection to using project boards for fixVersion tracking. Since I've already created project boards for each of the versions we're tracking with labels, and added all the issues to those boards that had the corresponding label, the only thing left to do is remove the (now useless) labels, and update the website/docs. I'll go ahead and do that.
On Fri, Jun 14, 2019 at 2:04 PM Christopher <ctubb...@apache.org> wrote: > > The automation features are a bit limited. You can't specify rules > based on labels. However, the whole point of this proposal is to > replace this particular use of labels, so that wouldn't necessarily > make sense anyway. > > On Fri, Jun 14, 2019 at 1:31 PM Owens, Mark <jmow...@evoforge.org> wrote: > > > > I like the look of the project boards based upon the ones that have been > > created. I like the 'in progress' feature. It will be helpful when looking > > for tickets as it will allow one to pass over issues without having to open > > each issue and looking for a comment stating that someone is looking at the > > issue. > > > > Are new issues still created from the main issues page and then > > automatically placed onto project boards based upon labels? > > > > > > -----Original Message----- > > From: Christopher <ctubb...@apache.org> > > Sent: Friday, June 14, 2019 12:31 PM > > To: accumulo-dev <dev@accumulo.apache.org> > > Subject: [DISCUSS] Project boards on GitHub > > > > 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
