Ideally, the JIRA work item should be created before coding starts -- long before the PR. So, I would suggest we don;t automatically create JIRAs because then it sort of defeats the purpose of JIRA managing a backlog.
On Thu, Mar 8, 2018 at 8:49 AM, Nan Zhu <zhunanmcg...@gmail.com> wrote: > +1 on both suggestions > > a bit concern is on the quality of JIRA which is created automatically > > I can see a lot of PRs are not described comprehensively, if we just post > what in description to JIRA, it's error-propagating > > > but the quality of JIRA is a big topic worth more discussions > > > > On Thu, Mar 8, 2018 at 3:06 AM, Marco de Abreu < > marco.g.ab...@googlemail.com > > wrote: > > > Would it be possible to automatically create JIRA tickets when a GitHub > > issue is being created? We could then mirror all comments the same way > it's > > happening in https://issues.apache.org/jira/projects/MXNET/issues/ > MXNET-42 > > but make sure that the bot works in both ways. A comment on GitHub would > be > > copied to JIRA and a JIRA comment to GitHub. I think this would be good > as > > a first step to start integration. > > > > -Marco > > > > On Wed, Mar 7, 2018 at 8:08 PM, Marco de Abreu < > > marco.g.ab...@googlemail.com > > > wrote: > > > > > I also see this as a big advantage in terms of transparency. I > personally > > > will try to move away from any company internal issue trackers (except > > for > > > confidential cases) and instead work on Jira that is being managed by > the > > > community. This allows everybody to see what is being worked on and > gives > > > them the possibility to chime with ideas or suggestions. > > > > > > In my opinion, this obsoletes TT and SIM to a big extent. It's up to > you > > > if you maintain multiple issue trackers or stick to one. If anybody > has a > > > (non-confidential) issue that's related to my work on CI, I ask them to > > > create a GitHub issue instead of a company internal ticket - I invite > > > everybody to do the same. > > > > > > MXNet is an open source project and moving away from company internal > > > trackers towards community driven ones is the next logical step in my > > > opinion. At the moment, everybody is working on their own and it's hard > > to > > > see for external people (or even developer who are not part of the same > > > team) what we're actually working on. > > > > > > -Marco > > > > > > On Wed, Mar 7, 2018 at 7:48 PM, Naveen Swamy <mnnav...@gmail.com> > wrote: > > > > > >> I am +1 for using JIRA. Managing bigger projects within MXNet on JIRA > > >> brings openness to the project. MXNet Users and the contributors also > > get > > >> a > > >> sense of where the project is heading. > > >> Bigger Tasks can be divided into sub-tasks which contributors can pick > > up > > >> small tasks based on their expertise on and contribute independently. > > >> > > >> On Wed, Mar 7, 2018 at 10:40 AM, Chris Olivier <cjolivie...@gmail.com > > > > >> wrote: > > >> > > >> > The vote was discussed on private@ before the vote on dev@, and the > > >> vote > > >> > went on for a very long time. There was ZERO resistance. No one > > >> "snuck" > > >> > it in or "slipped it by". > > >> > > > >> > This, hopefully, phases out both SIM and tt, which are both are > being > > >> used > > >> > in ways that aren't what they're even designed for, IMO. Trouble > > >> tickets > > >> > are being used as a backlog for my team, which is insane. > > >> > > > >> > I've actually sent out a couple of mails on dev about contact me if > > you > > >> > don't have access to JIRA. If you would like to participate in the > > >> > direction of the project, please keep up with the dev email list. > > >> > > > >> > I gave you contributor permissions on JIRA, btw. > > >> > . > > >> > > > >> > > > >> > > > >> > On Wed, Mar 7, 2018 at 10:17 AM, Aaron Markham < > > >> aaron.s.mark...@gmail.com> > > >> > wrote: > > >> > > > >> > > I'm not quite sure if I have enough background on reasons for or > > >> against > > >> > > this to vote in the next round, but my two cents: I didn't see > much > > >> > debate > > >> > > on why we need yet another tool for issues that we have to > manually > > >> > > maintain...the vote kind of slid in there without many > stakeholders > > >> > > realizing what they were being signed up for. I was thinking, > sure, > > if > > >> > YOU > > >> > > want to make jira tickets, go right ahead. I have two internal > > >> ticketing > > >> > > systems to deal with already that assign tasks on MXNet, plus > > GitHub. > > >> > Jira > > >> > > would be four. Happy to make it work, but I'll need fifth tool to > > >> > aggregate > > >> > > communications and metrics between the other four tools! I'm only > > >> sort of > > >> > > joking. > > >> > > > > >> > > I saw Chris's response, and ok the public visibility part makes > > sense, > > >> > but > > >> > > does this phase out any other overhead? Does it integrate? Jira > has > > >> > > integration options so maybe we can eliminate some overhead... > Like > > >> > > something that hooks into the GitHub api and generates jira > tickets > > on > > >> > the > > >> > > fly... I want to believe there's a plan that makes this all > easier. > > >> > > > > >> > > What value I don't see is how we lower barriers to contribution > and > > >> make > > >> > it > > >> > > more fluid for new users that could become contributors. What's > the > > >> story > > >> > > and value proposition? > > >> > > > > >> > > Also, I don't see any docs on the website or on github on how to > > sign > > >> up > > >> > > for jira, or how to contribute according to this new requirement > > >> anywhere > > >> > > on the site. Myself and new contributors wouldn't know what the > > >> expected > > >> > > flow looks like because it's not really accessible. I now see the > > >> > > confluence wiki, but that's pretty much hidden from anyone > browsing > > >> the > > >> > > site or github and looking to contribute. Why is this info on > > >> confluence > > >> > at > > >> > > all? Why not in the docs on github that are rendered to the > website? > > >> Or > > >> > > conversely, why is some of the info on github and on the website, > if > > >> it > > >> > is > > >> > > being maintained and current only on confluence? > > >> > > > > >> > > These are two separate issues really, but I think if you want > > buy-in, > > >> > this > > >> > > needs to be more transparent and obvious, and provide clear > reasons > > >> and > > >> > > benefits to why you're asking for more overhead. > > >> > > > > >> > > Aaron > > >> > > > > >> > > On Mar 6, 2018 21:14, "Eric Xie" <j...@apache.org> wrote: > > >> > > > > >> > > > -1 > > >> > > > > > >> > > > JIRA is ancient and arcane. This adds unnecessary overhead. > > >> > > > > > >> > > > On 2018/03/03 06:11:12, CodingCat <coding...@apache.org> wrote: > > >> > > > > This vote passes with 6 +1 votes (6 bindings) and no 0 or -1 > > >> votes. > > >> > > > > > > >> > > > > Binding +1: > > >> > > > > Chris Olivier > > >> > > > > Indhu Bharathi > > >> > > > > Suneel Marthi > > >> > > > > Yuan Tang > > >> > > > > Marco de Abreu > > >> > > > > Sebastian Schelter > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > Vote thread: > > >> > > > > https://lists.apache.org/list.html?d...@mxnet.apache.org:lte= > > >> > > > 1M:tracking%20code%20changes%20with%20JIRA%20by%20associatin > > >> > > > g%20pull%20requests > > >> > > > > > > >> > > > > I will continue with pushing the content to wiki and take it > > into > > >> > > > practice > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > > > > > > > >
