I am in full support of scrapping Jira, contributions will go much more
steadily.
Only code with a clear issue detailing the clear problem gets merged into
mainline. This must be law that goes hand in hand with numenta's engineers on
equal footing regarding information exposure to issues.
Kind regards
Stewart
Matthew Taylor <[email protected]> wrote:
>This is a proposal (based on our "lazy consensus" model[1]) to migrate
>our issue tracking system from JIRA[2] into Github Issues[3].
>
>We initially choose JIRA in order to make collaboration between
>internal Grok products (using JIRA) and the NuPIC project easier. It
>provided the same workflow for our planning meetings, scrums, etc. At
>this point, I don't believe the benefits we've received by doing this
>outweigh the simplicity and automatic integration of using Github
>Issues.
>
>I'd like to open this topic up for discussion to anyone with an
>opinion. Here are my thoughts, which are admittedly biased towards
>migrating to Github. I'd especially like to hear any dissenting
>opinions.
>
>1. JIRA requires users to create yet another user account to take part
>in ticket tracking
>2. JIRA / Github integration is not as easy as GH issue integration
>3. PRs are automatically tracked with GH issues, but usually go
>untracked in JIRA (unless they are manually linked to a JIRA ticket,
>which doesn't usually happen).
>4. JIRA does give us a nice "Agile View[4]" of our sprints, but I've
>found a project free for open source called huboard[5] that gives us
>the same functionality.
>5. With only GH and no JIRA, the identities of those commenting on
>tickets and committing code is obvious, while with JIRA I have no clue
>in some cases who people are, if they have signed our license, or if
>they have ever committed code.
>6. JIRA is complicated and flexible, and it takes discipline for all
>engineers on a team to use it in the same fashion. I cannot force
>everyone in the community to use all the standards necessary for a
>"rich JIRA experience". JIRA works great for Grok internally, but we
>all know (and have fought with) our own JIRA standards, and we have a
>PM who enforces the rules. I can't realistically enforce the same
>level of constraints on how JIRA tickets are created with the OS
>community, and I don't have time to clean up everyone's tickets.
>7. GH Issues would make my job easier, because I have one less system
>to deal with :)
>
>I want to move on this rather quickly, so please respond with your
>opinions by the end of this week. I'm going to be experimenting with
>GH issues on my own, and testing ticket migration scripts in the
>meantime.
>
>I will assume that silence == agreement. ;)
>
>Thanks!
>---------
>Matt Taylor
>OS Community Flag-Bearer
>Numenta
>
>[1]
>https://github.com/numenta/nupic/wiki/Contributor-Model#51-lazy-consensus
>[2] http://issues.numenta.org
>[3] https://github.com/features/projects/issues
>[4] https://issues.numenta.org/secure/RapidBoard.jspa?rapidView=2
>[5] https://huboard.com/
>
>_______________________________________________
>nupic mailing list
>[email protected]
>http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
nupic mailing list
[email protected]
http://lists.numenta.org/mailman/listinfo/nupic_lists.numenta.org
