Almost all Apache projects use JIRA. It's been proven to work in open-source. Having backlog/development process public hopefully will help adoption. Right now, what new users? Adoption is very slow, so I think it's hard to argue that the current way of doing things is effective.
On Thu, Mar 8, 2018 at 9:44 AM, Sheng Zha <szha....@gmail.com> wrote: > Cool. Feel free to propose a change to the PR template. > > How would JIRA be less daunting to new users? > > -sz > > > On Mar 8, 2018, at 9:25 AM, Chris Olivier <cjolivie...@gmail.com> wrote: > > > > My $0.02 about the PR template. > > > > I think it's a good idea. I think (just my opinion) is that the adoption > > is low because it started out too big and daunting. It may get more > > adoption if we started a little smaller -- with maybe two checkboxes" and > > also didn't have a line at the top stating "Description", because that > feel > > skind of awkward and github inserts extended label info above it > sometimes. > > > > Just an idea. > > > >> On Thu, Mar 8, 2018 at 9:13 AM, Sheng Zha <szha....@gmail.com> wrote: > >> > >> The PR template is designed for that and its poor adoption is causing > the > >> same issue of missing information in PRs. My concern of using JIRA is > that > >> more overhead would deter contribution and worsen the quality of > >> description. > >> > >> -sz > >> > >>> On 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 > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>>> > >>>> > >> >
