[Bro-Dev] Moving to GitHub?

[Jon Siwek]

On 5/18/18 11:11 AM, Robin Sommer wrote:

> What I was envisioning is more or less a clean slate: we'd migrate
> over a few tickets, but essentially we'd start with an empty list. I
> realize that sounds pretty harsh. However, I hardly ever see any
> activity on older tickets in JIRA, and I generally believe that the
> less open tickets a tracker has, the easier it is for people to
> understand what's actually relevant and worth spending cycles on.

I see those as independent issues:

(1) There's many open tickets: you solve that by actually addressing the 
tickets

(2) People don't know what tickets are relevant: you solve that by 
organizing (and maintaining) them according to relevance

My take is that there's been a lack of effort in (2) and if that's not 
solved, starting with a clean slate on GitHub now only means it's likely 
to eventually end up in the same situation as JIRA later.  What then? 
Move to another tracker again?

> Tagging tickets may help, but in the end if everybody just filters 95%
> out all the time anyways, I'm not sure what the value is.

The value is actually having a central place for all tickets and knowing 
there won't be ongoing hassle with keeping JIRA updated.

Or in reverse, I'm not sure what the value of keeping JIRA open at all 
is -- we either have to acknowledge its potential to go out of sync with 
GH in terms of duplicate reports, which makes it more of a hindrance 
IMO, or we still have to put effort to maintain it in addition to GH.

> That said, I'm open to a real porting effort if people do believe it's
> helpful to get all the JIRA tickets into GitHub. What do others think?

Pedantically, I'm not saying "port all JIRA tickets", I still want just 
the "valid" ones whatever we decide that to mean.  So more 
clarifications on potential porting criteria:

* Someone is likely to report the same problem again
* There's clear directions on how to reproduce an undesired behavior
* There been a proposed plan of action recently

And many tickets can be ruled out:

* Vague feature requests
* Not enough details  / difficult to reproduce
* Exceptionally old proposals / plans

My plea is: extend the porting criteria beyond "important" and "recent", 
perform a review of all existing tickets, and, if JIRA is going to stick 
around as a read-only archive, leave it in a coherent final state.

- Jon