just giving an example about Chris's opinion (how JIRA would help for more new users)
I can see Spark 2.4 is highly possible to include the nested column pruning in parquet file from its JIRA ( https://issues.apache.org/jira/browse/SPARK-4502) it's hard for me to have any source to get the similar expectation for MXNET Best, Nan On Thu, Mar 8, 2018 at 10:03 AM, Chris Olivier <cjolivie...@gmail.com> wrote: > 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 > > >>>>>>>>>> > > >>>>>>>>> > > >>>>>>>> > > >>>>>>> > > >>>>>> > > >>>>> > > >>>>> > > >>>> > > >> > > >
