Good points on keeping a public backlog. Should we expect new contributors to create such backlog items? Or who should own the responsibility of creating backlog items?
- Sent by my thumb > On Mar 8, 2018, at 10:14 AM, Nan Zhu <zhunanmcg...@gmail.com> wrote: > > 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 >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>> >>> >>
