+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 <[email protected]> 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 <[email protected]>: > > > 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 <[email protected]> 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 <[email protected]> wrote: > > > > > > > Are you saying only committers can make JIRA accounts? > > > > > > > > On Fri, Jun 8, 2018 at 2:41 PM Qing Lan <[email protected]> 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" <[email protected]> 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 < > [email protected] > > > > > > > > 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 < > > [email protected]> > > > > > 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 <[email protected] > > > > > > 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 < > > [email protected]> > > > > > 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 < > > > > > [email protected]> > > > > > > > > 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 < > > [email protected] > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
