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