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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
