Oh my God, no... On Thu, Mar 8, 2018 at 10:58 AM, Anirudh <anirudh2...@gmail.com> wrote:
> There should be an easy way to translate all the existing github issues > into work items in JIRA(Considering the work on labelling that is done for > github issues). > Does the JIRA bot handle this ? > > On Thu, Mar 8, 2018 at 10:40 AM, Chris Olivier <cjolivie...@gmail.com> > wrote: > > > Anyone can create a backlog item/JIRA ticket. > > > > Obvious cases might include: > > > > * Someone thinks of a task and (optionally) wants to develop it > themselves, > > so they create a backlog item and assign it to themself, putting it into > > "in progress" mode. > > * Someone dreams up a large feature and wants to create an epic with 30 > > subtasks, so they create the epic and its subtasks (grooming) > > * Someone wants to just pick up a random pre-existing backlog item to > work > > on > > > > I do think that backlog items should be restricted to actual work items > and > > not general issue reporting, but I'm certainly open to how other Apache > > projects like Spark do that. So far it seems like github issues do a > > pretty good job of that. > > > > > > On Thu, Mar 8, 2018 at 10:26 AM, Sheng Zha <szha....@gmail.com> wrote: > > > > > 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 > > > >>>>>>>>>>>>> > > > >>>>>>>>>>>> > > > >>>>>>>>>>> > > > >>>>>>>>>> > > > >>>>>>>>> > > > >>>>>>>> > > > >>>>>>>> > > > >>>>>>> > > > >>>>> > > > >>> > > > >> > > > > > >
