JIRA to GitHub ticket migration plan

Development
1

A preview of what migrated issues will look like along with new labeling scheme:

    https://github.com/jsiwek/test/issues

The selection strategy of which tickets to migrate is something like
"anything that is a reproducible bug or a simple/uncontroversial
enhancement". Any tickets not in that preview list will be left open
in JIRA, but frozen as read-only. Going forward, JIRA will serve as a
historical archive or Good Idea Backlog that we can occasionally pull
from, but that can be done manually whenever the situation comes up
(just create a GH issue and link to old JIRA ticket).

Remaining tasks:

* Perform the actual migration
* Update website/docs with new directions/process for issues
* Email bro + bro-dev mailing lists once tickets are migration
* Adapt workflow permissions for JIRA "BIT" project so it's read-only

I expect I'll do those next Monday unless there's objections or
feedback to address.

- Jon

2

A preview of what migrated issues will look like along with new labeling scheme:

Looks great, nice job. 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? So, say, all types would be green, all components yellow
(which they already are), etc.

Remaining tasks:

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?

Robin

3

> 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

4

Forgot to say that my sentiment is conditional -- if I find that it's
not disruptive/risky to the release process (e.g. whether I need to
make commits within bro itself), then changing whenever seems fine,
else wait until after 2.6.

It's maybe a week or two away before I have more complete
investigation/answer, but it's possibly that risky. Here's the
general things I'll be looking into and fleshing out:

* GitHub "protected branches" for permissions and access control
* Which private repos can actually be moved to GitHub (we'll need to
update to Team Account)
* Where all in the docs uses the old bro.org git URL.
* How to handle commit email notifications.
* How decouple-able is the script-reference building process. I'm
guessing I can just point to the github url and it will work, but
maybe there's some more we can offload from bro.org to Travis or AWS
at this point as well.

Anything else to worry about?

- Jon

5

Ok, thanks, makes sense.

Robin

6

Are Jenkins and Coverity already pulling from GitHub?

I don't know if there's anything we can do on the old server to make
existing clones deal with the relocation more gracefully. I don't
wthink there's a way just redirect a git client, but maybe we could get
some error message into the output or something? Not sure.

Robin

7

No, I thought Jenkins was pushing to Coverity.

Is the plan to have GitHub issues within each repo? That is, bro, binpac, etc. I think we’d lose the easy way to see all issues, but if I recall, there was a way in GitHub to see issues across a few repos. Maybe by organization?

–Vlad

8

Are Jenkins and Coverity already pulling from GitHub?

No, I thought Jenkins was pushing to Coverity.

Travis is triggered by commits on GitHub and looks like it has a
monthly cron to upload to Coverity.

However, some submodule + testing repos that Travis clones are
actually using the bro.org repo instead of github.com URL, but that's
maybe not something to try to change now, but rather wait until
performing the actual move.

Is the plan to have GitHub issues within each repo? That is, bro, binpac, etc. I think we'd lose the easy way to see all issues,

Yeah, issues are better kept within the associated GH repo. We rarely
saw JIRA tickets made for non-bro subcomponents and a good portion of
people were already using GitHub issues for those anyway.

but if I recall, there was a way in GitHub to see issues across a few repos. Maybe by organization?

Probably thinking of "project boards". You can create an
organization-wide board that contains issues from separate repos. I
haven't looked extensively at project boards, but I don't think it's
something we'll generally use because you have to manually add issues
to boards rather than treat them like an automated filter based on
issue labels/status/etc. That could make it more useful when
organizing specific long-term projects, but still likely decide to use
it on a case-by-case basis rather than generally.

- Jon