+0.5
I'm an SDE working for MXNet Engine team at AWS and I've been using JIRA
for nearly every single PR (28 out of 29 PR at this moment) I created since
I joined the team 3 months ago. I wouldn't say it's a really bad
experience, but definitely not good.
I do agree that we need something like JIRA and extra effort other than
writing code to manage the project, but the current user experience with
JIRA really has room for improvement.
The more important question for the community is that, is JIRA good for
attracting and retaining open source contributors? Such a user experience
of JIRA could drive contributors away if we're really enforcing it.
In conclusion, I think the usage of JIRA should be of one's or team's own
choice, if you do have the need to manage some development process (like
our team), just continue to use it, but we should no longer enforce or
persuade anyone to use it.
I'm also attaching a typical workflow of mine using JIRA with sprint
management and story point tracking for a single task, I think everyone who
has used JIRA so far would share part of my experience.
Thanks,
Hao
Appendix: what I need to do when I'm working on a task with JIRA:
1. Before I start working on something:
1) create a JIRA ticket for that, choose the correct type and define a
proper name for it
2) go to backlog page to add it to a sprint if you want to use the
sprint management.
3) go to sprint management page to assign story point value if you need
the functionality (we recently started doing that)
2. When I start working on the task:
1) dig my ticket up (on the sprint page or backlog page or search for
it)
2) click "open and start progress" to move it to "IN PROGRESS" phase.
3. When I finish the code, for every new PR I'll have to:
1) dig my ticket up
2) copy the ticket number so that I can add it to the PR title
3) an extra click to move the ticket to REVIEW phase
4) create a PR on github, paste the "MXNET-xxx" I just copied inside an
extra pair of square brackets "[]"
5) still need to refer the related github issue in the PR if I'm
solving one of them
4. For every code review or comment I receive on the new PR:
1) the JIRA bot logs 10 mins on the ticket no matter what kind of
comment it is
2) JIRA sends me an email for every single one of such logs (so if you
receive 10 code review comments in a single code review you get 10 emails,
my highest record was 17, while github would bundle all of them in only 1
mail)
5. After the PR is merged I get an email from JIRA saying this is merged
(for the bot, merge is like another comment on the PR) but I still have to:
1) dig my ticket up
2) manually move it to DONE phase (bot does not do that automatically).
6. The task is considered finished at this point, but any new comments on
the PR will trigger the bot once again to log 10 mins on your ticket
together with another email coming to your mailbox, while github is already
sending an email for that.
On Fri, Jun 8, 2018 at 2:23 PM, Naveen Swamy <mnnav...@gmail.com> wrote:
> Eric/Mu/Tianqi,
>
> A couple of contributors have used JIRA for the Scala project -- this is
> the first time, so there is some learning for us, We started off with a
> design proposal, followed by a call for contribution. We kept our progress
> open on the dev list and we found one contributor to help us during
> debugging/testing/maven package creation and also one of them is working on
> the Memory allocation issue in Scala not as a part of their day job; This
> is where I find value in managing the project features on JIRA, designs on
> the public wiki, etc.,. I am not claiming that this is perfect, this is a
> WIP and as a community we should give it a chance and try it out.
>
> I don't think most of us here have even looked at JIRA.
>
> P.S: I am traveling, my response will be delayed.
>
> -Naveen
>
>
> On Fri, Jun 8, 2018 at 12:34 PM, Anirudh <anirudh2...@gmail.com> wrote:
>
> > Hi,
> >
> > I am not a big fan of JIRA either. But I would like to raise this issue
> of
> > committing to a decision after a VOTE has passed. I saw in PRs that there
> > was a disregard for JIRA and ignoring requests on PRs to link to JIRA.
> > Because of this, JIRA was not given a fair chance to be tried out as a
> > project management tool and eventually hardly being used. If we don't
> work
> > on this as a community, VOTEs also tend to loose their meaning.
> >
> > Anirudh
> >
> >
> >
> > On Fri, Jun 8, 2018 at 11:00 AM, Eric Xie <j...@apache.org> wrote:
> >
> > > I think the number of issues become less of a problem if we label them
> > > timely, which is already improving.
> > >
> > > Thanks,
> > > Eric
> > >
> > > On 2018/06/08 17:55:28, Tianqi Chen <tqc...@cs.washington.edu> wrote:
> > > > I would suggest we have a separate discussion issue about
> transparency.
> > > > First of all, I agree that transparency is important.
> > > >
> > > > This can be achieved by public roadmaps, RFCs, that do not have
> > > > particularly tie to JIRA or github issues. Having a clear guideline
> on
> > > that
> > > > would be great, and it is great to see more RFCs in the dev list.
> > > >
> > > > In terms of issues themselves, I think one problem we are facing is
> > > > overflowing amount of issues. One way to minimize this would be to
> > > redirect
> > > > more questions to forums, and only keep issues that are actionable
> and
> > > > encourage the committers who opens the issue to fix them timely.
> > > >
> > > > Tianqi
> > > >
> > > > On Fri, Jun 8, 2018 at 10:35 AM, Naveen Swamy <mnnav...@gmail.com>
> > > wrote:
> > > >
> > > > > -1 (binding)
> > > > >
> > > > > The very reason why JIRA was suggested so that the project is more
> > > open on
> > > > > the features that are worked on. There are 900+ issues, that once
> in
> > a
> > > > > while gets closed without any reason has happened already once.
> > > > > There is already integration with GitHub PRs, please check it out.
> > > > >
> > > > > Features pop into the code-base without any discussion, they also
> get
> > > > > removed without any discussion. PRs come in when the feature is
> > > complete,
> > > > > not giving others opportunity to understand/contribute or have a
> > say.
> > > > >
> > > > > If this project embraces the true Apache spirit and follow
> successful
> > > > > practices we could get lot more people excited about this project.
> > Many
> > > > > successful Apache projects use JIRA, look at Apache Spark which has
> > > 1250+
> > > > > contributors and built a community of 500,000 people around the
> > world.
> > > > >
> > > > > -Naveen
> > > > >
> > > > >
> > > > > On Fri, Jun 8, 2018 at 10:27 AM, Eric Xie <j...@apache.org> wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > Since all of MXNet's development happens on Github, I think it's
> > > > > > sufficient to use Github Issues and Github Projects for tracking.
> > > There
> > > > > are
> > > > > > also many other plugins you can add to Github if issues and
> > projects
> > > are
> > > > > > not enough.
> > > > > >
> > > > > > It's very easy to cross reference PRs and issues for tracking. In
> > > > > > comparison, JIRA is an outdated system with very little features
> > and
> > > no
> > > > > > integration with Github. I think using it achieves nothing but
> > > additional
> > > > > > overhead.
> > > > > >
> > > > > > Thanks,
> > > > > > Eric
> > > > > >
> > > > >
> > > >
> > >
> >
>
