mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Xie <j...@apache.org>
Subject Re: Vote to stop using JIRA
Date Sat, 09 Jun 2018 00:05:53 GMT
Github has many project management tools. Any of them would be a better choice than JIRA.

Thanks,
Eric

On 2018/06/09 00:02:55, Timur Shenkao <tsh@timshenkao.su> wrote: 
> Hello guys!
> Let me add five cents step-by-step. Some kind of "external viewpoint" (I
> don't work in Amazon or Intel).
> 1) Thanks a lot of for interesting product / framework like MXNet.
> Currently, I use pretty standard DL stack: Keras + TF and some other less
> popular libraries. But I am not completely satisfied so I am looking for
> something new for my upcoming projects. So, I "investigate" MXNet now.
> 
> 2)* I completely agree with Naveen*.
> 
> 3) If you really want to see wide adoption of MXNet (like Spark, Kafka,
> Flink, etc.), then tasks should be documented in some task tracker.
> In this case everyone would be able to see the progress of the project,
> understand which features, bug fixes are included into the next release,
> intended to appear in near future. Developers, contributors, committers can
> see the progress, the cadence of the project. Links to docs, Github PRs,
> roadmaps, proposals, build results, other JIRAs are present in a JIRA
> ticket so it's easy to navigate for everyone.
> Github is suitable for code review and management. But it can't substitute
> tracker system. Even small team will have hundreds of PRs, issues pretty
> soon and chaos arises. Besides, there is no much fun (for "external" user)
> in jumping from one Github PR to another trying to understand why & when &
> in which commit something appeared.
> I understand that MXNet was promoted into Apache incubator to enlarge
> community, build ecosystem around it and for some other "commercial
> interests". Without clear vision and understanding of project's status &
> future, nobody will take MXNet into production or build MXNetT "plugin".
> 
> 4)  "*There are 900+ issues, that once in a while gets closed without any
> reason has happened already once*". It also happens with other Github-based
> projects. For example, Presto committers go through list of issues once or
> twice a year. And close vast majority of them with resolutions like "Won't
> fix", "I don't like it", etc.
> 
> 5) JIRA is very configurable, one does not have to jump from board to board
> to edit / enter ticket info. I have Apache's JIRA account. And I can read,
> add comments & files / patches to tickets, create tickets in some projects.
> But privileges can be configured.
> 
> 
> Timur
> 
> On Fri, Jun 8, 2018 at 10:48 PM, Hen <bayard@apache.org> wrote:
> 
> > 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
View raw message