mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jun Wu <wujun....@gmail.com>
Subject Re: Vote to stop using JIRA
Date Sat, 09 Jun 2018 03:53:45 GMT
+1

I have used Jira for a few years. At the time, it had much richer
customized features, at the cost of raising a specialized team developing
Jira plugins, than what the Jira system has for MXNet. Even so, I'm still
not a big fan of it. The learning curve is quite steep to make the personal
dashboard aligned with the team's. In the open source world, we can neither
afford having dedicated Jira support from a specialized team nor increasing
unnecessary overhead of developers. After using Jira for managing the
development work of MXNet for several months, I don't see any advantages of
using Jira with currently available features over GitHub Projects tracking
system.

On Fri, Jun 8, 2018 at 7:17 PM, Thomas DELTEIL <thomas.delteil1@gmail.com>
wrote:

> +0.5
>
> Thanks Timur for the constructive feedback!
>
> For me the problem is exactly as Anirudh raised, I am not a big fan of it
> but I don't think JIRA has been given a fair shot. The problem lies not so
> much with the tracking platform but rather with the contributors following
> the project management guidelines.
>
> All the best,
>
> Thomas
>
>
> 2018-06-08 17:05 GMT-07:00 Eric Xie <jxie@apache.org>:
>
> > 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message