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