On Fri, Sep 14, 2018 at 9:54 AM Robin Sommer <ro...@corelight.com> wrote: > > On Thu, Sep 13, 2018 at 19:39 -0500, Jon Siwek wrote: > > > A preview of what migrated issues will look like along with new labeling > > scheme: > > The only thing I noticed is that the labels are > quite long, making the list of tickets appear somewhat crowded. Could > we skip the prefixes ("Type:", "Component:") and instead use colors to > encode them?
I did some label tweaking and reduced some prefix names: "Component" -> "Area" and "Difficulty" -> "Pain". It's possible the color design could be done more carefully, but the basic idea is the colors are mostly encoding importance/difficulty. Green = go, yellow = caution, red = stop. That may help people scan the list to find potential things to work on related to their abilities or available time. A problem with removing the prefixes totally is that labels are sorted by name. So when one is viewing issues, they can get inconsistent label orders between issues: the priority label could be at the start, end, or middle of the label set. A more annoying thing is that when someone is trying to add labels to a new issue, they have to jump around a list to find which labels to add and there's not a clear end point. With prefixes, I can scan the list from top to bottom: pick an area, pick a pain, pick a priority, pick a type, done. Without prefixes, it's also less intuitive whether one should be mixing various labels together and accidentally pick two types that aren't meant to go together. Especially for those that are color blind, having a secondary way (the prefix) to distinguish label categories is a simple solution without having to do more color design and verification effort. I don't know enough to say how much a problem the current colors actually would be for what number of people, but trying to be thoughtful just in case. > We are leaving switching to github as authoritative source for the > repositories to later, right? Doing it all at the same time could > avoid confusion ("everything is on github now" is an easier > statement), but would also make the process more complex. Maybe the > real question here is if we want to switch repositories before or > after 2.6? I'd like to do the steps separately. Moving tickets shouldn't make the location of the git repo any more confusing than it is already. Some users are already using github instead of bro.org and devs are likely less-confusable anyway (or if not, it's still not a big deal if someone accidentally pushes commits to a non-master branch of github instead of bro.org). - Jon _______________________________________________ bro-dev mailing list bro-dev@bro.org http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev