mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hen <bay...@apache.org>
Subject Re: Vote to stop using JIRA
Date Fri, 08 Jun 2018 21:48:19 GMT
Are you saying only committers can make JIRA accounts?

On Fri, Jun 8, 2018 at 2:41 PM Qing Lan <lanking520@live.com> wrote:

> + 0
> Can we keep this optional? Not totally abandon or support.
> Pros:
> I used JIRA to track most of my PRs and can place them together at one
> place. It also being helpful if we find some issues and group them together
> as one case.
> Cons:
> Currently JIRA does not allow someone who is not contributor to file an
> issue which makes first-time contributor hard to submit a PR.
>
> Thanks,
> Qing
>
>
> ´╗┐On 6/8/18, 2:27 PM, "Hao Jin" <hjjn.amzn@gmail.com> wrote:
>
>     +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 <mnnaveen@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 <anirudh2290@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 <jxie@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 <tqchen@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 <
> mnnaveen@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 <jxie@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
>     > > > > > >
>     > > > > >
>     > > > >
>     > > >
>     > >
>     >
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message