To summarize: - JIRA might be more maintainer friendly(have more features for tracking progress etc.) - Github issues are more community friendly (it has been the way most people contribute, and have lower bar of entry).
Tianqi On Thu, Mar 8, 2018 at 11:05 AM, Xingjian SHI <xsh...@connect.ust.hk> wrote: > There is no issue page in Spark (https://github.com/apache/spark) and > they rely solely on JIRA to track the working items. This is different from > what we are doing now. MXNet associate PRs to working items by linking them > to the Github issues, e.g, https://github.com/apache/ > incubator-mxnet/pull/10029 links to https://github.com/apache/ > incubator-mxnet/issues/9950. If we rely on JIRA in the future, we need to > emphasize the difference between Github issues and JIRA items or disable > Github/issues and forces users to use JIRA. > > Personally, I think these two have similar functionalities and why don't > we directly use Github issues? It's much easier for users as they do not > need to create another account. Their contributions to MXNet (including > creating issues) would also be directly displayed in the Github homepage, > which encourages them to do more for the community. > > Best, > Xingjian > > > ________________________________ > From: Nan Zhu <zhunanmcg...@gmail.com> > Sent: Friday, March 9, 2018 2:14 AM > To: dev@mxnet.incubator.apache.org > Subject: Re: [RESULT][VOTE] tracking code changes with JIRA by associating > pull requests > > 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) > [SPARK-4502] Spark SQL reads unneccesary nested fields ...< > https://issues.apache.org/jira/browse/SPARK-4502> > issues.apache.org > When reading a field of a nested column from Parquet, SparkSQL reads and > assemble all the fields of that nested column. This is unnecessary, as > Parquet supports fine ... > > > > > 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 > > > >>>>>>>>>> > > > >>>>>>>>> > > > >>>>>>>> > > > >>>>>>> > > > >>>>>> > > > >>>>> > > > >>>>> > > > >>>> > > > >> > > > > > >
