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