On Mon, Mar 5, 2018 at 6:07 PM, Keith Turner <ke...@deenlo.com> wrote:
> On Thu, Feb 15, 2018 at 12:52 PM, Josh Elser <els...@apache.org> wrote:
>> -0 as an initial reaction because I'm still not convinced that GH issues
>> provides any additional features or better experience than JIRA does, and
>> this change would only serve to fragment an already bare community.
>> My concerns that would push that -0 to a -1 include (but aren't limited to):
>> * Documentation/website update for the release process
>> * Validation that our release processes on JIRA has similar functionality on
>> GH issues
>> * Updated contributor docs (removing JIRA related content, add an
>> explanation as to the change)
>> * CONTRIBUTING.md updated on relevant repos
> I opened the following PR with a proposal for how we could start using github.
> https://github.com/apache/accumulo-website/pull/59

There were lots of valid concerns raised during this discussion.  The
concerns shaped the proposal I submitted. Rather than reply to them
individually in different emails I am collecting them all here and
sharing my thoughts about them.

1. How do we release?

  JIRA is used in three important ways for releases : setting blockers,
  triaging issues, and generating release notes.  I think the proposal
  addresses all three.

2. Will we document contributor guidelines to avoid confusion?

  What is expected of contributors is clearly documented.

3. Can someone investigate how Spark operates before switching?

  That would be great if someone volunteered to do this and wrote up their
  findings.  However if no one volunteers, then I do not think this should
  be a blocker.  There are many other projects that would be worthy of
  investigation also.

4. What is the migration plan for existing issues?  Will we have split issue
   tracker for years?

  The proposal documents migrating existing JIRA issues as they are worked.
  This means that existing JIRA issues that are never worked will never
  migrate. After all branches are released, JIRA can be put in read only mode
  (only PMC can change it).  It will be left active for reference and
  migration of existing issues.

5. How will we handle fix versions?

   The proposal suggest using issue labels in github for this.  Also suggest
   using a prefix on fix version labels to make them sort last.

6. How will we handle security issues?

   We need to clearly document on our website how users should report
   security issues.  I am not sure this is done at the moment.  Since this
   is infrequent I think we can handle this on the private list.  I think
   our workflow should be optimized for frequent actions and not infrequent

7. Should we switch all repos to GH issues except Accumulo core?

   I think this a good example of how design by committee can go
   wrong.  This is a really confusing solution that does not
   improve our workflow, so the benefits are not clear to me.

>> - Josh
>> On 2/15/18 12:05 PM, Mike Walch wrote:
>>> I would like to open discussion on moving from Jira to GitHub issues.
>>> GitHub issues would be enabled for a trial period. After this trial
>>> period,
>>> the project would either move completely to GitHub issues or keep using
>>> Jira. Two issue trackers would not be used after trial period.

Reply via email to