mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Olivier <cjolivie...@gmail.com>
Subject Re: [RESULT][VOTE] tracking code changes with JIRA by associating pull requests
Date Thu, 08 Mar 2018 18:40:04 GMT
Anyone can create a backlog item/JIRA ticket.

Obvious cases might include:

* Someone thinks of a task and (optionally) wants to develop it themselves,
so they create a backlog item and assign it to themself, putting it into
"in progress" mode.
* Someone dreams up a large feature and wants to create an epic with 30
subtasks, so they create the epic and its subtasks (grooming)
* Someone wants to just pick up a random pre-existing backlog item to work
on

I do think that backlog items should be restricted to actual work items and
not general issue reporting, but I'm certainly open to how other Apache
projects like Spark do that.  So far it seems like github issues do a
pretty good job of that.


On Thu, Mar 8, 2018 at 10:26 AM, Sheng Zha <szha.pvg@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 <zhunanmcgill@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 <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/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" <jxie@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
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>
> >>>
> >>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message