You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@mxnet.apache.org by CodingCat <co...@apache.org> on 2018/03/03 06:11:12 UTC

[RESULT][VOTE] tracking code changes with JIRA by associating pull requests

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?dev@mxnet.apache.org:lte=1M:tracking%20code%20changes%20with%20JIRA%20by%20associating%20pull%20requests

I will continue with pushing the content to wiki and take it into practice

Re: [RESULT][VOTE] tracking code changes with JIRA by associating pull requests

Posted by Tianqi Chen <tq...@cs.washington.edu>.

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 <xs...@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 <zh...@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 <cj...@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 <sz...@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 <cj...@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 <sz...@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 <zh...@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.abreu@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.abreu@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 <
> mnnaveen@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 <
> > > cjolivier01@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.markham@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" <jx...@apache.org> wrote:
> > > >>>>>>>>>
> > > >>>>>>>>> -1
> > > >>>>>>>>>
> > > >>>>>>>>> JIRA is ancient and arcane. This adds unnecessary overhead.
> > > >>>>>>>>>
> > > >>>>>>>>>> On 2018/03/03 06:11:12, CodingCat <co...@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?dev@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
> > > >>>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>
> > > >>
> > >
> >
>

Re: [RESULT][VOTE] tracking code changes with JIRA by associating pull requests

Posted by Xingjian SHI <xs...@connect.ust.hk>.

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 <zh...@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 <cj...@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 <sz...@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 <cj...@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 <sz...@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 <zh...@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.abreu@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.abreu@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 <mn...@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 <
> > cjolivier01@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.markham@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" <jx...@apache.org> wrote:
> > >>>>>>>>>
> > >>>>>>>>> -1
> > >>>>>>>>>
> > >>>>>>>>> JIRA is ancient and arcane. This adds unnecessary overhead.
> > >>>>>>>>>
> > >>>>>>>>>> On 2018/03/03 06:11:12, CodingCat <co...@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?dev@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
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>
> > >>
> >
>

Re: [RESULT][VOTE] tracking code changes with JIRA by associating pull requests

Posted by Xingjian SHI <xs...@connect.ust.hk>.

We can also consider to give a special label for all the issues that are "working items". There are lots of efforts spent on assigning the correct label to Github issues. We can then easily select the issues we are interested in, e.g, https://github.com/apache/incubator-mxnet/issues?q=is%3Aopen+is%3Aissue+label%3A%22Feature+request%22


Xingjian


________________________________
From: Naveen Swamy <mn...@gmail.com>
Sent: Friday, March 9, 2018 3:08 AM
To: dev@mxnet.incubator.apache.org
Subject: Re: [RESULT][VOTE] tracking code changes with JIRA by associating pull requests

I don't think we should transfer all Github issues to Jira that will make
Jira issues unmanageable and pretty useless, also not all issues are being
worked on or will be worked on. I like the idea of using Jira as a backlog,
so contributors/committers create Jira tasks/projects based on what they
are working on.

On Thu, Mar 8, 2018 at 10:58 AM, Anirudh <an...@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 <cj...@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 <sz...@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 <zh...@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)
[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 <
> cjolivier01@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 <sz...@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 <cj...@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 <sz...@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 <zh...@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.abreu@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/
issues.apache.org<https://issues.apache.org/>
issues.apache.org
Apache currently hosts two different issue tracking systems, Bugzilla and Jira. To find out how to report an issue for a particular project, please visit the project ...



> > 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.abreu@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 <
> > mnnaveen@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 <
> > > >>> cjolivier01@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.markham@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" <jx...@apache.org> wrote:
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> -1
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> JIRA is ancient and arcane. This adds unnecessary
> overhead.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>> On 2018/03/03 06:11:12, CodingCat <co...@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?dev@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
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>
> > > >>>
> > > >>
> > >
> >
>

Re: [RESULT][VOTE] tracking code changes with JIRA by associating pull requests

Posted by Naveen Swamy <mn...@gmail.com>.

I don't think we should transfer all Github issues to Jira that will make
Jira issues unmanageable and pretty useless, also not all issues are being
worked on or will be worked on. I like the idea of using Jira as a backlog,
so contributors/committers create Jira tasks/projects based on what they
are working on.

On Thu, Mar 8, 2018 at 10:58 AM, Anirudh <an...@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 <cj...@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 <sz...@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 <zh...@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 <
> cjolivier01@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 <sz...@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 <cj...@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 <sz...@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 <zh...@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.abreu@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.abreu@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 <
> > mnnaveen@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 <
> > > >>> cjolivier01@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.markham@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" <jx...@apache.org> wrote:
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> -1
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> JIRA is ancient and arcane. This adds unnecessary
> overhead.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>> On 2018/03/03 06:11:12, CodingCat <co...@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?dev@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
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>
> > > >>>
> > > >>
> > >
> >
>

Re: [RESULT][VOTE] tracking code changes with JIRA by associating pull requests

Posted by Xingjian SHI <xs...@connect.ust.hk>.

How should we use Github issues if we do that? Currently it's supposed that issues are created before the PR.


Xingjian

________________________________
From: Chris Olivier <cj...@gmail.com>
Sent: Friday, March 9, 2018 3:44 AM
To: dev@mxnet.incubator.apache.org
Subject: Re: [RESULT][VOTE] tracking code changes with JIRA by associating pull requests

You should create the JIRA before you start work (long before the PR) so
that people know what's being worked on and don't overlap.  Ideally,
anything people work on should have been in JIRA for some time before work
starts so that there is some sort of holistic view of the direction of the
project rather than the way it is now, where PR's just appear out of
nowhere.

On Thu, Mar 8, 2018 at 11:38 AM, Xingjian SHI <xs...@connect.ust.hk> wrote:

> What's the expected workflow if we use JIRA? I'm not clear about that.
> Currently I'll 1) submit the PR, 2) describe what's done in the PR in
> detail and refer to the related Github issues, 3) create the JIRA item by
> copying the PR description, 4) change the title of the PR to
> [MXNET-JIRA_ID]ORIGINAL_TITLE. During the process I find step-3/4 are
> somehow unnecessary.
>
>
> Best,
>
> Xingjian
>
> ________________________________
> From: Naveen Swamy <mn...@gmail.com>
> Sent: Friday, March 9, 2018 3:26 AM
> To: dev@mxnet.incubator.apache.org
> Subject: Re: [RESULT][VOTE] tracking code changes with JIRA by associating
> pull requests
>
> Whether to use Jira or not is a moot point now,  I suggest lets discuss how
> to use Github/Jira effectively, to make it easy for contributors(new and
> veterans). Let us use it for 6 months or so and collect feedback, people
> who don't find it useful can start another VOTE.
>
>
> On Thu, Mar 8, 2018 at 11:17 AM, Chris Olivier <cj...@gmail.com>
> wrote:
>
> > Oh my God, no...
> >
> > On Thu, Mar 8, 2018 at 10:58 AM, Anirudh <an...@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 <cj...@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 <sz...@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 <zh...@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)
[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 ...



> [SPARK-4502] Spark SQL reads unneccesary nested fields ...<
> 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 ...



> 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 <
> > > cjolivier01@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 <sz...@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 <
> > cjolivier01@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.pvg@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 <zhunanmcgill@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.abreu@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/
issues.apache.org<https://issues.apache.org/>
issues.apache.org
Apache currently hosts two different issue tracking systems, Bugzilla and Jira. To find out how to report an issue for a particular project, please visit the project ...



> issues.apache.org<https://issues.apache.org/>
issues.apache.org<https://issues.apache.org/>
issues.apache.org
Apache currently hosts two different issue tracking systems, Bugzilla and Jira. To find out how to report an issue for a particular project, please visit the project ...



> issues.apache.org
> Apache currently hosts two different issue tracking systems, Bugzilla and
> Jira. To find out how to report an issue for a particular project, please
> visit the project ...
>
>
>
> > > > 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.abreu@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 <
> > > > mnnaveen@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 <
> > > > > >>> cjolivier01@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.markham@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" <jx...@apache.org>
> > wrote:
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>>> -1
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>>> JIRA is ancient and arcane. This adds unnecessary
> > > overhead.
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>>>> On 2018/03/03 06:11:12, CodingCat <
> > codingcat@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?dev@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
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>
> > > > > >>>>>
> > > > > >>>
> > > > > >>
> > > > >
> > > >
> > >
> >
>

Re: [RESULT][VOTE] tracking code changes with JIRA by associating pull requests

Posted by Chris Olivier <cj...@gmail.com>.

Workflow should be:

1. Create JIRA or select JIRA from backlog
2. Mark JIRA as "In Progress"
3. Work on code and submit PR
the PR needs to start with [MXNET-XXX]
that way the JIRA has the latest updates from github
4. Once PR has been approved., commit the PR
5. Mark the Jira as Resolved and then Closed


On Thu, Mar 8, 2018 at 11:44 AM, Chris Olivier <cj...@gmail.com>
wrote:

> You should create the JIRA before you start work (long before the PR) so
> that people know what's being worked on and don't overlap.  Ideally,
> anything people work on should have been in JIRA for some time before work
> starts so that there is some sort of holistic view of the direction of the
> project rather than the way it is now, where PR's just appear out of
> nowhere.
>
> On Thu, Mar 8, 2018 at 11:38 AM, Xingjian SHI <xs...@connect.ust.hk>
> wrote:
>
>> What's the expected workflow if we use JIRA? I'm not clear about that.
>> Currently I'll 1) submit the PR, 2) describe what's done in the PR in
>> detail and refer to the related Github issues, 3) create the JIRA item by
>> copying the PR description, 4) change the title of the PR to
>> [MXNET-JIRA_ID]ORIGINAL_TITLE. During the process I find step-3/4 are
>> somehow unnecessary.
>>
>>
>> Best,
>>
>> Xingjian
>>
>> ________________________________
>> From: Naveen Swamy <mn...@gmail.com>
>> Sent: Friday, March 9, 2018 3:26 AM
>> To: dev@mxnet.incubator.apache.org
>> Subject: Re: [RESULT][VOTE] tracking code changes with JIRA by
>> associating pull requests
>>
>> Whether to use Jira or not is a moot point now,  I suggest lets discuss
>> how
>> to use Github/Jira effectively, to make it easy for contributors(new and
>> veterans). Let us use it for 6 months or so and collect feedback, people
>> who don't find it useful can start another VOTE.
>>
>>
>> On Thu, Mar 8, 2018 at 11:17 AM, Chris Olivier <cj...@gmail.com>
>> wrote:
>>
>> > Oh my God, no...
>> >
>> > On Thu, Mar 8, 2018 at 10:58 AM, Anirudh <an...@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 <cjolivier01@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 <sz...@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 <zh...@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)
>> [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 <
>> > > cjolivier01@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.pvg@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 <
>> > cjolivier01@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.pvg@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 <
>> zhunanmcgill@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.abreu@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/
>> issues.apache.org<https://issues.apache.org/>
>> issues.apache.org
>> Apache currently hosts two different issue tracking systems, Bugzilla and
>> Jira. To find out how to report an issue for a particular project, please
>> visit the project ...
>>
>>
>>
>> > > > 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.abreu@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 <
>> > > > mnnaveen@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 <
>> > > > > >>> cjolivier01@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.markham@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" <jx...@apache.org>
>> > wrote:
>> > > > > >>>>>>>>>>>>
>> > > > > >>>>>>>>>>>> -1
>> > > > > >>>>>>>>>>>>
>> > > > > >>>>>>>>>>>> JIRA is ancient and arcane. This adds unnecessary
>> > > overhead.
>> > > > > >>>>>>>>>>>>
>> > > > > >>>>>>>>>>>>> On 2018/03/03 06:11:12, CodingCat <
>> > codingcat@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?dev@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
>> > > > > >>>>>>>>>>>>>
>> > > > > >>>>>>>>>>>>
>> > > > > >>>>>>>>>>>
>> > > > > >>>>>>>>>>
>> > > > > >>>>>>>>>
>> > > > > >>>>>>>>
>> > > > > >>>>>>>>
>> > > > > >>>>>>>
>> > > > > >>>>>
>> > > > > >>>
>> > > > > >>
>> > > > >
>> > > >
>> > >
>> >
>>
>
>

Re: [RESULT][VOTE] tracking code changes with JIRA by associating pull requests

Posted by Chris Olivier <cj...@gmail.com>.

You should create the JIRA before you start work (long before the PR) so
that people know what's being worked on and don't overlap.  Ideally,
anything people work on should have been in JIRA for some time before work
starts so that there is some sort of holistic view of the direction of the
project rather than the way it is now, where PR's just appear out of
nowhere.

On Thu, Mar 8, 2018 at 11:38 AM, Xingjian SHI <xs...@connect.ust.hk> wrote:

> What's the expected workflow if we use JIRA? I'm not clear about that.
> Currently I'll 1) submit the PR, 2) describe what's done in the PR in
> detail and refer to the related Github issues, 3) create the JIRA item by
> copying the PR description, 4) change the title of the PR to
> [MXNET-JIRA_ID]ORIGINAL_TITLE. During the process I find step-3/4 are
> somehow unnecessary.
>
>
> Best,
>
> Xingjian
>
> ________________________________
> From: Naveen Swamy <mn...@gmail.com>
> Sent: Friday, March 9, 2018 3:26 AM
> To: dev@mxnet.incubator.apache.org
> Subject: Re: [RESULT][VOTE] tracking code changes with JIRA by associating
> pull requests
>
> Whether to use Jira or not is a moot point now,  I suggest lets discuss how
> to use Github/Jira effectively, to make it easy for contributors(new and
> veterans). Let us use it for 6 months or so and collect feedback, people
> who don't find it useful can start another VOTE.
>
>
> On Thu, Mar 8, 2018 at 11:17 AM, Chris Olivier <cj...@gmail.com>
> wrote:
>
> > Oh my God, no...
> >
> > On Thu, Mar 8, 2018 at 10:58 AM, Anirudh <an...@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 <cj...@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 <sz...@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 <zh...@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)
> [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 <
> > > cjolivier01@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 <sz...@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 <
> > cjolivier01@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.pvg@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 <zhunanmcgill@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.abreu@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/
> issues.apache.org<https://issues.apache.org/>
> issues.apache.org
> Apache currently hosts two different issue tracking systems, Bugzilla and
> Jira. To find out how to report an issue for a particular project, please
> visit the project ...
>
>
>
> > > > 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.abreu@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 <
> > > > mnnaveen@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 <
> > > > > >>> cjolivier01@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.markham@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" <jx...@apache.org>
> > wrote:
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>>> -1
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>>> JIRA is ancient and arcane. This adds unnecessary
> > > overhead.
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>>>> On 2018/03/03 06:11:12, CodingCat <
> > codingcat@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?dev@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
> > > > > >>>>>>>>>>>>>
> > > > > >>>>>>>>>>>>
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>
> > > > > >>>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>>
> > > > > >>>>>>>
> > > > > >>>>>
> > > > > >>>
> > > > > >>
> > > > >
> > > >
> > >
> >
>

Re: [RESULT][VOTE] tracking code changes with JIRA by associating pull requests

Posted by Xingjian SHI <xs...@connect.ust.hk>.

What's the expected workflow if we use JIRA? I'm not clear about that. Currently I'll 1) submit the PR, 2) describe what's done in the PR in detail and refer to the related Github issues, 3) create the JIRA item by copying the PR description, 4) change the title of the PR to [MXNET-JIRA_ID]ORIGINAL_TITLE. During the process I find step-3/4 are somehow unnecessary.


Best,

Xingjian

________________________________
From: Naveen Swamy <mn...@gmail.com>
Sent: Friday, March 9, 2018 3:26 AM
To: dev@mxnet.incubator.apache.org
Subject: Re: [RESULT][VOTE] tracking code changes with JIRA by associating pull requests

Whether to use Jira or not is a moot point now,  I suggest lets discuss how
to use Github/Jira effectively, to make it easy for contributors(new and
veterans). Let us use it for 6 months or so and collect feedback, people
who don't find it useful can start another VOTE.


On Thu, Mar 8, 2018 at 11:17 AM, Chris Olivier <cj...@gmail.com>
wrote:

> Oh my God, no...
>
> On Thu, Mar 8, 2018 at 10:58 AM, Anirudh <an...@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 <cj...@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 <sz...@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 <zh...@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)
[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 <
> > cjolivier01@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 <sz...@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 <
> cjolivier01@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 <sz...@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 <zh...@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.abreu@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/
issues.apache.org<https://issues.apache.org/>
issues.apache.org
Apache currently hosts two different issue tracking systems, Bugzilla and Jira. To find out how to report an issue for a particular project, please visit the project ...



> > > 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.abreu@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 <
> > > mnnaveen@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 <
> > > > >>> cjolivier01@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.markham@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" <jx...@apache.org>
> wrote:
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> -1
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> JIRA is ancient and arcane. This adds unnecessary
> > overhead.
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>>> On 2018/03/03 06:11:12, CodingCat <
> codingcat@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?dev@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
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>
> > > > >>>>>
> > > > >>>
> > > > >>
> > > >
> > >
> >
>

Re: [RESULT][VOTE] tracking code changes with JIRA by associating pull requests

Posted by Naveen Swamy <mn...@gmail.com>.

Whether to use Jira or not is a moot point now,  I suggest lets discuss how
to use Github/Jira effectively, to make it easy for contributors(new and
veterans). Let us use it for 6 months or so and collect feedback, people
who don't find it useful can start another VOTE.


On Thu, Mar 8, 2018 at 11:17 AM, Chris Olivier <cj...@gmail.com>
wrote:

> Oh my God, no...
>
> On Thu, Mar 8, 2018 at 10:58 AM, Anirudh <an...@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 <cj...@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 <sz...@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 <zh...@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 <
> > cjolivier01@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 <sz...@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 <
> cjolivier01@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 <sz...@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 <zh...@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.abreu@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.abreu@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 <
> > > mnnaveen@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 <
> > > > >>> cjolivier01@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.markham@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" <jx...@apache.org>
> wrote:
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> -1
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> JIRA is ancient and arcane. This adds unnecessary
> > overhead.
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>>> On 2018/03/03 06:11:12, CodingCat <
> codingcat@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?dev@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
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>
> > > > >>>>>
> > > > >>>
> > > > >>
> > > >
> > >
> >
>

Re: [RESULT][VOTE] tracking code changes with JIRA by associating pull requests

Posted by Anirudh <an...@gmail.com>.

There are a lot of issues out there which can be translated to work
items(for e.g. labels such as "Call For Contribution", "Feature" and "Bugs")
There should be an easy way to translate these to work items in JIRA.

On Thu, Mar 8, 2018 at 11:17 AM, Chris Olivier <cj...@gmail.com>
wrote:

> Oh my God, no...
>
> On Thu, Mar 8, 2018 at 10:58 AM, Anirudh <an...@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 <cj...@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 <sz...@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 <zh...@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 <
> > cjolivier01@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 <sz...@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 <
> cjolivier01@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 <sz...@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 <zh...@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.abreu@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.abreu@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 <
> > > mnnaveen@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 <
> > > > >>> cjolivier01@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.markham@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" <jx...@apache.org>
> wrote:
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> -1
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> JIRA is ancient and arcane. This adds unnecessary
> > overhead.
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>>> On 2018/03/03 06:11:12, CodingCat <
> codingcat@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?dev@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
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>
> > > > >>>>>
> > > > >>>
> > > > >>
> > > >
> > >
> >
>

Re: [RESULT][VOTE] tracking code changes with JIRA by associating pull requests

Posted by Chris Olivier <cj...@gmail.com>.

Oh my God, no...

On Thu, Mar 8, 2018 at 10:58 AM, Anirudh <an...@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 <cj...@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 <sz...@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 <zh...@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 <
> cjolivier01@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 <sz...@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 <cj...@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 <sz...@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 <zh...@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.abreu@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.abreu@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 <
> > mnnaveen@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 <
> > > >>> cjolivier01@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.markham@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" <jx...@apache.org> wrote:
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> -1
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> JIRA is ancient and arcane. This adds unnecessary
> overhead.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>> On 2018/03/03 06:11:12, CodingCat <co...@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?dev@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
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>
> > > >>>
> > > >>
> > >
> >
>

Re: [RESULT][VOTE] tracking code changes with JIRA by associating pull requests

Posted by Anirudh <an...@gmail.com>.

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 <cj...@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 <sz...@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 <zh...@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 <cj...@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 <sz...@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 <cj...@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 <sz...@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 <zh...@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.abreu@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.abreu@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 <
> mnnaveen@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 <
> > >>> cjolivier01@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.markham@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" <jx...@apache.org> wrote:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> -1
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> JIRA is ancient and arcane. This adds unnecessary overhead.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>> On 2018/03/03 06:11:12, CodingCat <co...@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?dev@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
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>
> > >>>
> > >>
> >
>

Re: [RESULT][VOTE] tracking code changes with JIRA by associating pull requests

Posted by Chris Olivier <cj...@gmail.com>.

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 <sz...@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 <zh...@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 <cj...@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 <sz...@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 <cj...@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 <sz...@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 <zh...@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.abreu@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.abreu@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 <mnnaveen@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 <
> >>> cjolivier01@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.markham@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" <jx...@apache.org> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> -1
> >>>>>>>>>>>>
> >>>>>>>>>>>> JIRA is ancient and arcane. This adds unnecessary overhead.
> >>>>>>>>>>>>
> >>>>>>>>>>>>> On 2018/03/03 06:11:12, CodingCat <co...@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?dev@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
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>
> >>>
> >>
>

Re: [RESULT][VOTE] tracking code changes with JIRA by associating pull requests

Posted by Sheng Zha <sz...@gmail.com>.

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 <zh...@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 <cj...@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 <sz...@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 <cj...@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 <sz...@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 <zh...@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.abreu@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.abreu@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 <mn...@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 <
>>> cjolivier01@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.markham@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" <jx...@apache.org> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> -1
>>>>>>>>>>>> 
>>>>>>>>>>>> JIRA is ancient and arcane. This adds unnecessary overhead.
>>>>>>>>>>>> 
>>>>>>>>>>>>> On 2018/03/03 06:11:12, CodingCat <co...@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?dev@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
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>> 
>>> 
>>

Re: [RESULT][VOTE] tracking code changes with JIRA by associating pull requests

Posted by Nan Zhu <zh...@gmail.com>.

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 <cj...@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 <sz...@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 <cj...@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 <sz...@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 <zh...@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.abreu@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.abreu@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 <mn...@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 <
> > cjolivier01@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.markham@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" <jx...@apache.org> wrote:
> > >>>>>>>>>
> > >>>>>>>>> -1
> > >>>>>>>>>
> > >>>>>>>>> JIRA is ancient and arcane. This adds unnecessary overhead.
> > >>>>>>>>>
> > >>>>>>>>>> On 2018/03/03 06:11:12, CodingCat <co...@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?dev@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
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>
> > >>
> >
>

Re: [RESULT][VOTE] tracking code changes with JIRA by associating pull requests

Posted by Chris Olivier <cj...@gmail.com>.

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 <sz...@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 <cj...@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 <sz...@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 <zh...@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.abreu@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.abreu@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 <mn...@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 <
> cjolivier01@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.markham@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" <jx...@apache.org> wrote:
> >>>>>>>>>
> >>>>>>>>> -1
> >>>>>>>>>
> >>>>>>>>> JIRA is ancient and arcane. This adds unnecessary overhead.
> >>>>>>>>>
> >>>>>>>>>> On 2018/03/03 06:11:12, CodingCat <co...@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?dev@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
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>
>

Re: [RESULT][VOTE] tracking code changes with JIRA by associating pull requests

Posted by Sheng Zha <sz...@gmail.com>.

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 <cj...@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 <sz...@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 <zh...@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.abreu@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.abreu@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 <mn...@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 <cjolivier01@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.markham@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" <jx...@apache.org> wrote:
>>>>>>>>> 
>>>>>>>>> -1
>>>>>>>>> 
>>>>>>>>> JIRA is ancient and arcane. This adds unnecessary overhead.
>>>>>>>>> 
>>>>>>>>>> On 2018/03/03 06:11:12, CodingCat <co...@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?dev@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
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>

Re: [RESULT][VOTE] tracking code changes with JIRA by associating pull requests

Posted by Chris Olivier <cj...@gmail.com>.

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 <sz...@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 <zh...@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.abreu@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.abreu@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 <mn...@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 <cjolivier01@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.markham@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" <jx...@apache.org> wrote:
> >>>>>>>
> >>>>>>> -1
> >>>>>>>
> >>>>>>> JIRA is ancient and arcane. This adds unnecessary overhead.
> >>>>>>>
> >>>>>>>> On 2018/03/03 06:11:12, CodingCat <co...@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?dev@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
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>>
> >>
>

Re: [RESULT][VOTE] tracking code changes with JIRA by associating pull requests

Posted by Sheng Zha <sz...@gmail.com>.

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 <zh...@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.abreu@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.abreu@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 <mn...@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 <cj...@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.markham@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" <jx...@apache.org> wrote:
>>>>>>> 
>>>>>>> -1
>>>>>>> 
>>>>>>> JIRA is ancient and arcane. This adds unnecessary overhead.
>>>>>>> 
>>>>>>>> On 2018/03/03 06:11:12, CodingCat <co...@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?dev@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
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
>>

Re: [RESULT][VOTE] tracking code changes with JIRA by associating pull requests

Posted by Chris Olivier <cj...@gmail.com>.

Ideally, the JIRA work item should be created before coding starts -- long
before the PR.  So, I would suggest we don;t automatically create JIRAs
because then it sort of defeats the purpose of JIRA managing a backlog.

On Thu, Mar 8, 2018 at 8:49 AM, Nan Zhu <zh...@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.abreu@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.abreu@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 <mn...@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 <cjolivier01@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.markham@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" <jx...@apache.org> wrote:
> > >> > >
> > >> > > > -1
> > >> > > >
> > >> > > > JIRA is ancient and arcane. This adds unnecessary overhead.
> > >> > > >
> > >> > > > On 2018/03/03 06:11:12, CodingCat <co...@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?dev@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
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> > >
> >
>

Re: [RESULT][VOTE] tracking code changes with JIRA by associating pull requests

Posted by Nan Zhu <zh...@gmail.com>.

+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.abreu@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.abreu@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 <mn...@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 <cj...@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.markham@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" <jx...@apache.org> wrote:
> >> > >
> >> > > > -1
> >> > > >
> >> > > > JIRA is ancient and arcane. This adds unnecessary overhead.
> >> > > >
> >> > > > On 2018/03/03 06:11:12, CodingCat <co...@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?dev@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
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >
> >
>

Re: [RESULT][VOTE] tracking code changes with JIRA by associating pull requests

Posted by Marco de Abreu <ma...@googlemail.com>.

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.abreu@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 <mn...@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 <cj...@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.markham@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" <jx...@apache.org> wrote:
>> > >
>> > > > -1
>> > > >
>> > > > JIRA is ancient and arcane. This adds unnecessary overhead.
>> > > >
>> > > > On 2018/03/03 06:11:12, CodingCat <co...@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?dev@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
>> > > > >
>> > > >
>> > >
>> >
>>
>
>

Re: [RESULT][VOTE] tracking code changes with JIRA by associating pull requests

Posted by Marco de Abreu <ma...@googlemail.com>.

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 <mn...@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 <cj...@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.markham@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" <jx...@apache.org> wrote:
> > >
> > > > -1
> > > >
> > > > JIRA is ancient and arcane. This adds unnecessary overhead.
> > > >
> > > > On 2018/03/03 06:11:12, CodingCat <co...@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?dev@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
> > > > >
> > > >
> > >
> >
>

Re: [RESULT][VOTE] tracking code changes with JIRA by associating pull requests

Posted by Naveen Swamy <mn...@gmail.com>.

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 <cj...@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 <aa...@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" <jx...@apache.org> wrote:
> >
> > > -1
> > >
> > > JIRA is ancient and arcane. This adds unnecessary overhead.
> > >
> > > On 2018/03/03 06:11:12, CodingCat <co...@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?dev@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
> > > >
> > >
> >
>

Re: [RESULT][VOTE] tracking code changes with JIRA by associating pull requests

Posted by Chris Olivier <cj...@gmail.com>.

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 <aa...@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" <jx...@apache.org> wrote:
>
> > -1
> >
> > JIRA is ancient and arcane. This adds unnecessary overhead.
> >
> > On 2018/03/03 06:11:12, CodingCat <co...@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?dev@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
> > >
> >
>

Re: [RESULT][VOTE] tracking code changes with JIRA by associating pull requests

Posted by Aaron Markham <aa...@gmail.com>.

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" <jx...@apache.org> wrote:

> -1
>
> JIRA is ancient and arcane. This adds unnecessary overhead.
>
> On 2018/03/03 06:11:12, CodingCat <co...@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?dev@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
> >
>

Re: [RESULT][VOTE] tracking code changes with JIRA by associating pull requests

Posted by Marco de Abreu <ma...@googlemail.com>.

Would it be possible to add the instruction to the PR template (along with
a link to Jira) in order to provide users with an easy way to create an
issue if required.

-Marco

On Wed, Mar 7, 2018 at 6:34 AM, Chris Olivier <cj...@gmail.com> wrote:

> Eric,
>
> while you may not be, most people are using some sort of
> crappy-JIRA-like-tool (such as SIM) which is both way behind JIRA in
> utility and usability as well as not public, so the rest of the world can’t
> see the backlog or what work orders are or whatever. the development
> process does not appear open, and this may contribute to the slow adoption
> of mxnet.
> a lot of us are also struggling with internal
> ticketing tools which are kind of rude to use for non-critical problems,
> IMHO and JIRA can help to alleviate these pain-points by having a place to
> translate github issues to work items.
>
> not sure how it could be considered arcane. compared to what?
>
> github has issues such as you must be a committer to assign an item, as
> well as other issues revolving around write access to the repository. in
> addition, it’s a pretty feature-weak tool compared to JIRA both in
> scrum/kanban/module/etc ways as well as reporting tools. github is still
> useful for issue reporting, with JIRA being actual work-items (something
> there is no public equivalent today)
>
>
>
> On Tue, Mar 6, 2018 at 9:22 PM Nan Zhu <zh...@gmail.com> wrote:
>
> > I think the right approach here is to start another vote on terminate the
> > starting process of using JIRA,
> >
> > since we have passed this vote
> >
> > On Tue, Mar 6, 2018 at 9:13 PM, Eric Xie <jx...@apache.org> wrote:
> >
> > > -1
> > >
> > > JIRA is ancient and arcane. This adds unnecessary overhead.
> > >
> > > On 2018/03/03 06:11:12, CodingCat <co...@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?dev@mxnet.apache.org:lte=
> > > 1M:tracking%20code%20changes%20with%20JIRA%20by%20associating%20pull%
> > > 20requests
> > > >
> > > > I will continue with pushing the content to wiki and take it into
> > > practice
> > > >
> > >
> >
>

Re: [RESULT][VOTE] tracking code changes with JIRA by associating pull requests

Posted by Chris Olivier <cj...@gmail.com>.

Eric,

while you may not be, most people are using some sort of
crappy-JIRA-like-tool (such as SIM) which is both way behind JIRA in
utility and usability as well as not public, so the rest of the world can’t
see the backlog or what work orders are or whatever. the development
process does not appear open, and this may contribute to the slow adoption
of mxnet.
a lot of us are also struggling with internal
ticketing tools which are kind of rude to use for non-critical problems,
IMHO and JIRA can help to alleviate these pain-points by having a place to
translate github issues to work items.

not sure how it could be considered arcane. compared to what?

github has issues such as you must be a committer to assign an item, as
well as other issues revolving around write access to the repository. in
addition, it’s a pretty feature-weak tool compared to JIRA both in
scrum/kanban/module/etc ways as well as reporting tools. github is still
useful for issue reporting, with JIRA being actual work-items (something
there is no public equivalent today)

On Tue, Mar 6, 2018 at 9:22 PM Nan Zhu <zh...@gmail.com> wrote:

> I think the right approach here is to start another vote on terminate the
> starting process of using JIRA,
>
> since we have passed this vote
>
> On Tue, Mar 6, 2018 at 9:13 PM, Eric Xie <jx...@apache.org> wrote:
>
> > -1
> >
> > JIRA is ancient and arcane. This adds unnecessary overhead.
> >
> > On 2018/03/03 06:11:12, CodingCat <co...@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?dev@mxnet.apache.org:lte=
> > 1M:tracking%20code%20changes%20with%20JIRA%20by%20associating%20pull%
> > 20requests
> > >
> > > I will continue with pushing the content to wiki and take it into
> > practice
> > >
> >
>

Re: [RESULT][VOTE] tracking code changes with JIRA by associating pull requests

Posted by Nan Zhu <zh...@gmail.com>.

I think the right approach here is to start another vote on terminate the
starting process of using JIRA,

since we have passed this vote

On Tue, Mar 6, 2018 at 9:13 PM, Eric Xie <jx...@apache.org> wrote:

> -1
>
> JIRA is ancient and arcane. This adds unnecessary overhead.
>
> On 2018/03/03 06:11:12, CodingCat <co...@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?dev@mxnet.apache.org:lte=
> 1M:tracking%20code%20changes%20with%20JIRA%20by%20associating%20pull%
> 20requests
> >
> > I will continue with pushing the content to wiki and take it into
> practice
> >
>

Re: [RESULT][VOTE] tracking code changes with JIRA by associating pull requests

Posted by Eric Xie <jx...@apache.org>.

-1

JIRA is ancient and arcane. This adds unnecessary overhead.

On 2018/03/03 06:11:12, CodingCat <co...@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?dev@mxnet.apache.org:lte=1M:tracking%20code%20changes%20with%20JIRA%20by%20associating%20pull%20requests
> 
> I will continue with pushing the content to wiki and take it into practice
>