mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas DELTEIL <thomas.delte...@gmail.com>
Subject Re: Vote to stop using JIRA
Date Sat, 09 Jun 2018 02:17:01 GMT
+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