[Bro-Dev] JIRA to GitHub ticket migration plan

[Jon Siwek]

On Fri, Sep 14, 2018 at 9:54 AM Robin Sommer <robin at 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