Re: Vote to stop using JIRA

[Timur Shenkao]

Hello!

In parallel e-mail thread, people shared Apache Beam experience on
community building. So I decided  not to re-invent the wheel and bring
together my personal experience and other Apache projects' knowledge.
This is like short cheat sheet:
https://drive.google.com/file/d/1L47T_E9AHYeL3SvatGYAWig0m3eTX27l to get
started.

One needs to define:
-- list of shepherds
-- components
-- mail list (like user@mxnet... or jira@mxnet)

If all PRs have corresponding JIRAs, then release notes can be generated
with a click of a button.
Labels are not mandatory but they make life much easier.


Timur

On Fri, Jun 29, 2018 at 7:08 AM, Timur Shenkao  wrote:

> I can devote some time this weekend and start writing some draft proposal.
> Then we can add it to Confluence and other people will be able to
> elaborate it.
>
> But I believe some workflow description is already present in Apache
> materials
>
> On Thu, Jun 28, 2018 at 9:23 PM, Marco de Abreu <
> marco.g.ab...@googlemail.com.invalid> wrote:
>
>> Hi Yasser,
>>
>> agree, the environment is already set up properly. The problem we have is
>> that we are lacking people who are familiar with the system and who would
>> like to help us leading the JIRA related efforts. This could include
>> things
>> like kicking off a few JIRA projects, setting up permissions properly,
>> spreading the knowledge, creating a good project management flow as well
>> as
>> mentoring us in how far we can improve.
>>
>> @Pedro: No, JIRA tickets should not be closed automatically. A JIRA ticket
>> might be a bigger story or be referenced by multiple PRs, thus it would be
>> misleading if they'd be auto-closed.
>>
>> -Marco
>>
>> On Thu, Jun 28, 2018 at 7:24 PM Pedro Larroy <
>> pedro.larroy.li...@gmail.com>
>> wrote:
>>
>> > Am I doing something wrong? When my PRs get merged, JIRA issues don't
>> get
>> > closed:
>> >
>> > https://issues.apache.org/jira/browse/MXNET-460
>> >
>> > @YiZhi Liu: as per PR instructions, a JIRA ticket is not required for
>> minor
>> > patches, only for things that you would include in release notes.
>> >
>> > Pedro.
>> >
>> > On Thu, Jun 28, 2018 at 4:15 AM Yasser Zamani 
>> > wrote:
>> >
>> > > Hello Marco, I hope best,
>> > >
>> > > Thank you for your email, however, as I mentioned in following links,
>> I
>> > > see MXNet already has configured project management boards in Jira
>> and it
>> > > seems people have assigned related tasks there, I mean I see it's
>> already
>> > > working and we don't need an extra To Do, right?
>> > >
>> > > Regards.
>> > > On Jun 27, 2018, at 4:31 PM, Marco de Abreu <
>> > marco.g.ab...@googlemail.com
>> > > .invalid> wrote:
>> > >
>> > > Hello Yasser,
>> > > I'd like to check back with you and ask if you need any assistance or
>> if
>> > > there is anything else we can do. Please feel free to shoot me a
>> private
>> > > email so we can set up a 1:1 to discuss ideas and solutions.
>> > > -Marco
>> > >
>> > > On Wed, Jun 13, 2018 at 10:02 AM Yasser Zamani <
>> yasserzam...@apache.org>
>> > > wrote:
>> > >
>> > >
>> > >
>> > >  On 6/11/2018 8:53 PM, Marco de Abreu wrote:
>> > >  How about you set up a personal instance of JIRA (let us know if the
>> > >  public
>> > >  ones differ too much from the one we're running under Apache) and
>> play
>> > >  around a bit? We can then review the setup and migrate the necessary
>> > >  changes after everything looks good.
>> > >
>> > >  I'm pleased to say that fortunately it seems MXNet already has both
>> > >  Kanban [1] and Scrum [2] project management boards :)
>> > >
>> > >  Regards.
>> > >
>> > >  [1] https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidV
>> iew=237
>> > >  [2] https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidV
>> iew=211
>> > >
>> > >
>> >
>>
>
>

Re: Vote to stop using JIRA

[Timur Shenkao]

I can devote some time this weekend and start writing some draft proposal.
Then we can add it to Confluence and other people will be able to elaborate
it.

But I believe some workflow description is already present in Apache
materials

On Thu, Jun 28, 2018 at 9:23 PM, Marco de Abreu <
marco.g.ab...@googlemail.com.invalid> wrote:

> Hi Yasser,
>
> agree, the environment is already set up properly. The problem we have is
> that we are lacking people who are familiar with the system and who would
> like to help us leading the JIRA related efforts. This could include things
> like kicking off a few JIRA projects, setting up permissions properly,
> spreading the knowledge, creating a good project management flow as well as
> mentoring us in how far we can improve.
>
> @Pedro: No, JIRA tickets should not be closed automatically. A JIRA ticket
> might be a bigger story or be referenced by multiple PRs, thus it would be
> misleading if they'd be auto-closed.
>
> -Marco
>
> On Thu, Jun 28, 2018 at 7:24 PM Pedro Larroy  >
> wrote:
>
> > Am I doing something wrong? When my PRs get merged, JIRA issues don't get
> > closed:
> >
> > https://issues.apache.org/jira/browse/MXNET-460
> >
> > @YiZhi Liu: as per PR instructions, a JIRA ticket is not required for
> minor
> > patches, only for things that you would include in release notes.
> >
> > Pedro.
> >
> > On Thu, Jun 28, 2018 at 4:15 AM Yasser Zamani 
> > wrote:
> >
> > > Hello Marco, I hope best,
> > >
> > > Thank you for your email, however, as I mentioned in following links, I
> > > see MXNet already has configured project management boards in Jira and
> it
> > > seems people have assigned related tasks there, I mean I see it's
> already
> > > working and we don't need an extra To Do, right?
> > >
> > > Regards.
> > > On Jun 27, 2018, at 4:31 PM, Marco de Abreu <
> > marco.g.ab...@googlemail.com
> > > .invalid> wrote:
> > >
> > > Hello Yasser,
> > > I'd like to check back with you and ask if you need any assistance or
> if
> > > there is anything else we can do. Please feel free to shoot me a
> private
> > > email so we can set up a 1:1 to discuss ideas and solutions.
> > > -Marco
> > >
> > > On Wed, Jun 13, 2018 at 10:02 AM Yasser Zamani <
> yasserzam...@apache.org>
> > > wrote:
> > >
> > >
> > >
> > >  On 6/11/2018 8:53 PM, Marco de Abreu wrote:
> > >  How about you set up a personal instance of JIRA (let us know if the
> > >  public
> > >  ones differ too much from the one we're running under Apache) and play
> > >  around a bit? We can then review the setup and migrate the necessary
> > >  changes after everything looks good.
> > >
> > >  I'm pleased to say that fortunately it seems MXNet already has both
> > >  Kanban [1] and Scrum [2] project management boards :)
> > >
> > >  Regards.
> > >
> > >  [1] https://issues.apache.org/jira/secure/RapidBoard.jspa?
> rapidView=237
> > >  [2] https://issues.apache.org/jira/secure/RapidBoard.jspa?
> rapidView=211
> > >
> > >
> >
>

Re: Vote to stop using JIRA

[Marco de Abreu]

Hi Yasser,

agree, the environment is already set up properly. The problem we have is
that we are lacking people who are familiar with the system and who would
like to help us leading the JIRA related efforts. This could include things
like kicking off a few JIRA projects, setting up permissions properly,
spreading the knowledge, creating a good project management flow as well as
mentoring us in how far we can improve.

@Pedro: No, JIRA tickets should not be closed automatically. A JIRA ticket
might be a bigger story or be referenced by multiple PRs, thus it would be
misleading if they'd be auto-closed.

-Marco

On Thu, Jun 28, 2018 at 7:24 PM Pedro Larroy 
wrote:

> Am I doing something wrong? When my PRs get merged, JIRA issues don't get
> closed:
>
> https://issues.apache.org/jira/browse/MXNET-460
>
> @YiZhi Liu: as per PR instructions, a JIRA ticket is not required for minor
> patches, only for things that you would include in release notes.
>
> Pedro.
>
> On Thu, Jun 28, 2018 at 4:15 AM Yasser Zamani 
> wrote:
>
> > Hello Marco, I hope best,
> >
> > Thank you for your email, however, as I mentioned in following links, I
> > see MXNet already has configured project management boards in Jira and it
> > seems people have assigned related tasks there, I mean I see it's already
> > working and we don't need an extra To Do, right?
> >
> > Regards.
> > On Jun 27, 2018, at 4:31 PM, Marco de Abreu <
> marco.g.ab...@googlemail.com
> > .invalid> wrote:
> >
> > Hello Yasser,
> > I'd like to check back with you and ask if you need any assistance or if
> > there is anything else we can do. Please feel free to shoot me a private
> > email so we can set up a 1:1 to discuss ideas and solutions.
> > -Marco
> >
> > On Wed, Jun 13, 2018 at 10:02 AM Yasser Zamani 
> > wrote:
> >
> >
> >
> >  On 6/11/2018 8:53 PM, Marco de Abreu wrote:
> >  How about you set up a personal instance of JIRA (let us know if the
> >  public
> >  ones differ too much from the one we're running under Apache) and play
> >  around a bit? We can then review the setup and migrate the necessary
> >  changes after everything looks good.
> >
> >  I'm pleased to say that fortunately it seems MXNet already has both
> >  Kanban [1] and Scrum [2] project management boards :)
> >
> >  Regards.
> >
> >  [1] https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=237
> >  [2] https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=211
> >
> >
>

Re: Vote to stop using JIRA

[Pedro Larroy]

Am I doing something wrong? When my PRs get merged, JIRA issues don't get
closed:

https://issues.apache.org/jira/browse/MXNET-460

@YiZhi Liu: as per PR instructions, a JIRA ticket is not required for minor
patches, only for things that you would include in release notes.

Pedro.

On Thu, Jun 28, 2018 at 4:15 AM Yasser Zamani 
wrote:

> Hello Marco, I hope best,
>
> Thank you for your email, however, as I mentioned in following links, I
> see MXNet already has configured project management boards in Jira and it
> seems people have assigned related tasks there, I mean I see it's already
> working and we don't need an extra To Do, right?
>
> Regards.
> On Jun 27, 2018, at 4:31 PM, Marco de Abreu  .invalid> wrote:
>
> Hello Yasser,
> I'd like to check back with you and ask if you need any assistance or if
> there is anything else we can do. Please feel free to shoot me a private
> email so we can set up a 1:1 to discuss ideas and solutions.
> -Marco
>
> On Wed, Jun 13, 2018 at 10:02 AM Yasser Zamani 
> wrote:
>
>
>
>  On 6/11/2018 8:53 PM, Marco de Abreu wrote:
>  How about you set up a personal instance of JIRA (let us know if the
>  public
>  ones differ too much from the one we're running under Apache) and play
>  around a bit? We can then review the setup and migrate the necessary
>  changes after everything looks good.
>
>  I'm pleased to say that fortunately it seems MXNet already has both
>  Kanban [1] and Scrum [2] project management boards :)
>
>  Regards.
>
>  [1] https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=237
>  [2] https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=211
>
>

Re: Vote to stop using JIRA

[Marco de Abreu]

Hello Yasser,
I'd like to check back with you and ask if you need any assistance or if
there is anything else we can do. Please feel free to shoot me a private
email so we can set up a 1:1 to discuss ideas and solutions.
-Marco

On Wed, Jun 13, 2018 at 10:02 AM Yasser Zamani 
wrote:

>
>
> On 6/11/2018 8:53 PM, Marco de Abreu wrote:
> > How about you set up a personal instance of JIRA (let us know if the
> public
> > ones differ too much from the one we're running under Apache) and play
> > around a bit? We can then review the setup and migrate the necessary
> > changes after everything looks good.
>
> I'm pleased to say that fortunately it seems MXNet already has both
> Kanban [1] and Scrum [2] project management boards :)
>
> Regards.
>
> [1] https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=237
> [2] https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=211
>

Re: Vote to stop using JIRA

[YiZhi Liu]

I feel so far our 'jira process' is not well organized. Though I agree
with Steffen that Jira may be valuable for management task in some
cases, it is not good to force every PR tie with a JIRA task. For
example, I don't think this one worth a JIRA:
https://github.com/apache/incubator-mxnet/pull/11225 . I did see PRs
with only tens of line changes been blocked by reviewers, just because
there's no related JIRA task. That's too brute and definitely not
friendly to new contributors.

If one (or a team) has a task need to be tracked, e.g., it is a large
feature, or it will be improved or fixed later, etc, I think it might
be fine to tracked by JIRA. If someone met problems, spent 10 minutes
fixed, shot a PR, it does not make sense to stick a red-cross and say,
a JIRA is required.
On Mon, Jun 11, 2018 at 9:52 AM Timur Shenkao  wrote:
>
> > I like GitHub for it's  good community integration - just mention
> somebody or link it in another issue/PR and everything will automatically
> be referenced; pretty neat.
> Take a look at
> https://issues.apache.org/jira/projects/SPARK/issues/SPARK-14220?filter=allopenissues
>
> BTW Spark is also "complex" multi-language project.
> They also had problems with long running builds and test jobs
>
> On Mon, Jun 11, 2018 at 5:23 PM, Marco de Abreu <
> marco.g.ab...@googlemail.com> wrote:
>
> > Thanks for this detailed description!
> >
> > I think GitHub and JIRA are a good thing to co-exist. GitHub for issues and
> > JIRA for action items (as a result of the issues). I like GitHub for it's
> > good community integration - just mention somebody or link it in another
> > issue/PR and everything will automatically be referenced; pretty neat.
> >
> > How about you set up a personal instance of JIRA (let us know if the public
> > ones differ too much from the one we're running under Apache) and play
> > around a bit? We can then review the setup and migrate the necessary
> > changes after everything looks good. But sure, if anybody at @dev has
> > further experience, I'd love to see them involved.
> >
> > -Marco
> >
> > On Mon, Jun 11, 2018 at 7:22 AM Yasser Zamani 
> > wrote:
> >
> > >
> > >
> > > On 6/11/2018 6:32 PM, Sebastian wrote:
> > > > Looks like they also don't handle the committer nomination process
> > > > correctly ...
> > > >
> > > > "If you are interested in becoming a Weex committer, contact any
> > > > existing committer and we will help you go through the invitation
> > > process."
> > >
> > > Yes you're absolutely right. Contributors wouldn't ask for this,
> > > instead, they will be nominated. In some cases like this [1] we're
> > > better than Weex :)
> > >
> > > [1] https://cwiki.apache.org/confluence/display/MXNET/
> > Becoming+a+Committer
> > >
> >



-- 
Yizhi Liu
DMLC member
Amazon Web Services
Vancouver, Canada

Re: Vote to stop using JIRA

[Timur Shenkao]

> I like GitHub for it's  good community integration - just mention
somebody or link it in another issue/PR and everything will automatically
be referenced; pretty neat.
Take a look at
https://issues.apache.org/jira/projects/SPARK/issues/SPARK-14220?filter=allopenissues

BTW Spark is also "complex" multi-language project.
They also had problems with long running builds and test jobs

On Mon, Jun 11, 2018 at 5:23 PM, Marco de Abreu <
marco.g.ab...@googlemail.com> wrote:

> Thanks for this detailed description!
>
> I think GitHub and JIRA are a good thing to co-exist. GitHub for issues and
> JIRA for action items (as a result of the issues). I like GitHub for it's
> good community integration - just mention somebody or link it in another
> issue/PR and everything will automatically be referenced; pretty neat.
>
> How about you set up a personal instance of JIRA (let us know if the public
> ones differ too much from the one we're running under Apache) and play
> around a bit? We can then review the setup and migrate the necessary
> changes after everything looks good. But sure, if anybody at @dev has
> further experience, I'd love to see them involved.
>
> -Marco
>
> On Mon, Jun 11, 2018 at 7:22 AM Yasser Zamani 
> wrote:
>
> >
> >
> > On 6/11/2018 6:32 PM, Sebastian wrote:
> > > Looks like they also don't handle the committer nomination process
> > > correctly ...
> > >
> > > "If you are interested in becoming a Weex committer, contact any
> > > existing committer and we will help you go through the invitation
> > process."
> >
> > Yes you're absolutely right. Contributors wouldn't ask for this,
> > instead, they will be nominated. In some cases like this [1] we're
> > better than Weex :)
> >
> > [1] https://cwiki.apache.org/confluence/display/MXNET/
> Becoming+a+Committer
> >
>

Re: Vote to stop using JIRA

[Marco de Abreu]

Thanks for this detailed description!

I think GitHub and JIRA are a good thing to co-exist. GitHub for issues and
JIRA for action items (as a result of the issues). I like GitHub for it's
good community integration - just mention somebody or link it in another
issue/PR and everything will automatically be referenced; pretty neat.

How about you set up a personal instance of JIRA (let us know if the public
ones differ too much from the one we're running under Apache) and play
around a bit? We can then review the setup and migrate the necessary
changes after everything looks good. But sure, if anybody at @dev has
further experience, I'd love to see them involved.

-Marco

On Mon, Jun 11, 2018 at 7:22 AM Yasser Zamani 
wrote:

>
>
> On 6/11/2018 6:32 PM, Sebastian wrote:
> > Looks like they also don't handle the committer nomination process
> > correctly ...
> >
> > "If you are interested in becoming a Weex committer, contact any
> > existing committer and we will help you go through the invitation
> process."
>
> Yes you're absolutely right. Contributors wouldn't ask for this,
> instead, they will be nominated. In some cases like this [1] we're
> better than Weex :)
>
> [1] https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer
>

Re: Vote to stop using JIRA

[Yasser Zamani]

On 6/11/2018 6:32 PM, Sebastian wrote:
> Looks like they also don't handle the committer nomination process
> correctly ...
> 
> "If you are interested in becoming a Weex committer, contact any
> existing committer and we will help you go through the invitation process."

Yes you're absolutely right. Contributors wouldn't ask for this,
instead, they will be nominated. In some cases like this [1] we're
better than Weex :)

[1] https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer

Re: Vote to stop using JIRA

[Sebastian]

Looks like they also don't handle the committer nomination process 
correctly ...


"If you are interested in becoming a Weex committer, contact any 
existing committer and we will help you go through the invitation process."


On 11.06.2018 05:31, Yasser Zamani wrote:



On 6/10/2018 4:53 AM, Marco de Abreu wrote:

Thanks a lot, this sounds like a good start. We definitely do not want to
re-invent the wheel - if there's some setup we can copy, I'd love to do
that as well!

Something we need is the possibility to have projects with subtasks and the
ability for any contributor (not committer) to contribute to these
projects. This could be adding tasks, changing the state of a task, maybe
even labelling and other things you usually do if you work on systems like
a Kanban-board. We want to give contributors the possibility to manage a
project entirely on their own without much involvement of committers.



I researched Apache Incubator Projects to find most similar project to
MXNet and found weex [1] which has these similar properties:

Several expertise: Java, JavaScript, Objective-C, C++, Objective-C++.
High revolutionary commits and issues: [2] [3].
High number of concurrent contributors: [2] ( ~ 1/4 MXNet).

Although it isn't as hard to manage as MXNet but I found these very
helpful and good things there:

- They have been disabled GitHub issues but use Pull Request with JIRA.
- They have contribution protocols [4] (e.g. how PR JIRA connection).
- They have defined How to Contribute [5] Bug Report Guidelines [6] and
Development Process [7].

Additionally, with a lot of thanks to your keyword "Kanban-board", I
found following hopeful amazing things about JIRA:

* Learn kanban with Jira software [8].
* Learn how to create agile boards in Jira Software [9].
* JIRA: Monitoring work in a Kanban project [10].
* What is kanban? [11].

I'm new to these and MXNet and firstly I was planned to have code
contributions, but now, it will be my honor and motivation if you @dev
have time to let me research these and come back with good setup and
docs in a timely manner. Or we can also ask in @dev if anyone has such
experiences and can bring us such setup and docs customized to MXNet.

Warm Regards.

[1] http://weex.incubator.apache.org/
[2] https://github.com/apache/incubator-weex/graphs/contributors
[3]
https://issues.apache.org/jira/projects/WEEX/issues/WEEX-450?filter=allissues
[4] https://github.com/apache/incubator-weex/blob/master/CONTRIBUTING.md
[5] http://weex.incubator.apache.org/contributing.html
[6] http://weex.incubator.apache.org/bug-report-guidelines.html
[7] http://weex.incubator.apache.org/development-process.html
[8]
https://www.atlassian.com/agile/tutorials/how-to-do-kanban-with-jira-software
[9] https://www.atlassian.com/agile/tutorials/creating-your-agile-board
[10]
https://confluence.atlassian.com/jirasoftwarecloud/monitoring-work-in-a-kanban-project-764478148.html
[11] https://www.atlassian.com/agile/kanban

Re: Vote to stop using JIRA

[Yasser Zamani]

On 6/10/2018 4:53 AM, Marco de Abreu wrote:
> Thanks a lot, this sounds like a good start. We definitely do not want to
> re-invent the wheel - if there's some setup we can copy, I'd love to do
> that as well!
> 
> Something we need is the possibility to have projects with subtasks and the
> ability for any contributor (not committer) to contribute to these
> projects. This could be adding tasks, changing the state of a task, maybe
> even labelling and other things you usually do if you work on systems like
> a Kanban-board. We want to give contributors the possibility to manage a
> project entirely on their own without much involvement of committers.


I researched Apache Incubator Projects to find most similar project to
MXNet and found weex [1] which has these similar properties:

Several expertise: Java, JavaScript, Objective-C, C++, Objective-C++.
High revolutionary commits and issues: [2] [3].
High number of concurrent contributors: [2] ( ~ 1/4 MXNet).

Although it isn't as hard to manage as MXNet but I found these very
helpful and good things there:

- They have been disabled GitHub issues but use Pull Request with JIRA.
- They have contribution protocols [4] (e.g. how PR JIRA connection).
- They have defined How to Contribute [5] Bug Report Guidelines [6] and
Development Process [7].

Additionally, with a lot of thanks to your keyword "Kanban-board", I
found following hopeful amazing things about JIRA:

* Learn kanban with Jira software [8].
* Learn how to create agile boards in Jira Software [9].
* JIRA: Monitoring work in a Kanban project [10].
* What is kanban? [11].

I'm new to these and MXNet and firstly I was planned to have code
contributions, but now, it will be my honor and motivation if you @dev
have time to let me research these and come back with good setup and
docs in a timely manner. Or we can also ask in @dev if anyone has such
experiences and can bring us such setup and docs customized to MXNet.

Warm Regards.

[1] http://weex.incubator.apache.org/
[2] https://github.com/apache/incubator-weex/graphs/contributors
[3]
https://issues.apache.org/jira/projects/WEEX/issues/WEEX-450?filter=allissues
[4] https://github.com/apache/incubator-weex/blob/master/CONTRIBUTING.md
[5] http://weex.incubator.apache.org/contributing.html
[6] http://weex.incubator.apache.org/bug-report-guidelines.html
[7] http://weex.incubator.apache.org/development-process.html
[8]
https://www.atlassian.com/agile/tutorials/how-to-do-kanban-with-jira-software
[9] https://www.atlassian.com/agile/tutorials/creating-your-agile-board
[10]
https://confluence.atlassian.com/jirasoftwarecloud/monitoring-work-in-a-kanban-project-764478148.html
[11] https://www.atlassian.com/agile/kanban

Re: Vote to stop using JIRA

[Chris Olivier]

-1 (binding)

Even though the community voted to use JIRA, there is a substantial group of 
people who have not adopted JIRA and continue using github in earnest as a 
project management tool.  Probably we should turn off github issues as a 
forcing function, although it was left on to help the transition (rather than 
to help to ignore JIRA altogether, which was what happenned).

Calling JIRA antiquated and featureless is curious, since as far as I have 
seen, it is a far more sophisticated and feature-rich project management tool 
in almost every way to github.  I would like to see some sort of feature 
comparison to substantiate this claim that github is more feature-rich and Jira 
is "featureless".  This statement makes me suspect that the claimant has simply 
never used it.

We have outsiders/new users in this thread who prefer it, which I think is 
worth 1000 Amazon votes each, and we should listen.

If we want to win over other Apache contributors, then JIRA is a step towards 
that.  It's there along with other projects, getting visibiity and will 
hopefully peak interest.  There's a lot of Apache devlopers and we could use 
some of them on mxnt.  

One thing I can say for for sure is that mxnet adoption is currently abysmal, 
so something needs to change (obviously).  I am reminded of Einstein's famous 
quote: "Insanity is doing the same thing over and over and expecting different 
results".

-Chris

On 2018/06/08 17:27:13, Eric Xie  wrote: 
> Hi,
> 
> Since all of MXNet's development happens on Github, I think it's sufficient 
> to use Github Issues and Github Projects for tracking. There are also many 
> other plugins you can add to Github if issues and projects are not enough.
> 
> It's very easy to cross reference PRs and issues for tracking. In comparison, 
> JIRA is an outdated system with very little features and no integration with 
> Github. I think using it achieves nothing but additional overhead.
> 
> Thanks,
> Eric
> 

Re: Vote to stop using JIRA

[Steffen Rochel]

As a contributor I have no github permissions to do even the simplest
project management task - I can't neither add a label, provide information
about priority/severity of an issue nor add issues to projects etc. Given
the current github permission difference between committer and
contributors  and our stated goal to grow the size and participation of the
community, I disagree that github provides sufficient project management
features and capabilities.

While our current Jira setup has a lot of opportunity for improvements, it
does allow contributors to participate in some level of project management.
E.g. with recently added capability to use story points we can measure
velocity and make estimations of project completions.
As we are discussing alternatives, I would encourage to consider the desire
of contributors to support the project in more than just code
contributions, i.e. requirements for both contributors and committers for a
low overhead project management solution.

Steffen

On Sat, Jun 9, 2018 at 11:43 PM Sebastian  wrote:

>
>
> > -1 as I afraid it may violate "Apache Way". Microsoft is going to buy
> > GitHub. What happens to Apache histories if one day he decided to drop
> > GitHub data including Apache projects histories?! or decided to change
> > usage license or payment?! and etc!
> >
> > However, I found it seems was legally OK in 2016 [1] BUT I think we must
> > ask again also "general@incubator and/or community@apache and/or board
> > rather than at legal-discuss" [1]. (at least informs them about the
> > state of the art).
>
> I don't think we need to worry about Microsoft buying Github at the
> moment and this should also not affect this discussion. If Apache
> becomes unhappy with github at some point in time, we can just move the
> code (to which github does not have any claims) someplace else.
>
> -sebastian
>

Re: Vote to stop using JIRA

[Sergio Fernández]

Hi,

I'm not going to express my opinion on this matter, because the community
is who has to decide what's best for the project.

I just want to say that there is no ASF/Incubator requirement that a
project/podling must use Jira as issue tracking system. There are other
projects using other hosted tools (for  instance, Tomcat uses Bugzilla),
and there are projects relying on GitHub issues (e.g., OpenWhisk).
Personally I think Jira brings quite some benefits, but it comes at a cost.
In any case, you just need to properly prepare INFRA to have a backup of
all the activities of the project relying on third party services (as you
have with GitBox).

Cheers,



On Sat, Jun 9, 2018, 17:23 Marco de Abreu 
wrote:

> Thanks a lot, this sounds like a good start. We definitely do not want to
> re-invent the wheel - if there's some setup we can copy, I'd love to do
> that as well!
>
> Something we need is the possibility to have projects with subtasks and the
> ability for any contributor (not committer) to contribute to these
> projects. This could be adding tasks, changing the state of a task, maybe
> even labelling and other things you usually do if you work on systems like
> a Kanban-board. We want to give contributors the possibility to manage a
> project entirely on their own without much involvement of committers.
>
> -Marco
>
> On Sat, Jun 9, 2018 at 5:32 PM Yasser Zamani 
> wrote:
>
> >
> >
> > On 6/9/2018 5:01 PM, Marco de Abreu wrote:
> > > Would you mind creating a proposal document at
> > > [1], describing what you would have in mind and how project planning,
> > > -management, development, planning, third-party-engagements and other
> > > things you can think of would look like then?
> >
> > Yes of course. However, I think we don't have to reinvent the wheel. I'm
> > almost sure there are projects in Apache (either incubating or not)
> > which have similar general properties like MXNet. e.g. from Apache
> > reports, we can see which incubating (or not) project has a lot of
> > monthly revolutionary changes or issues while needs several different
> > contribution expertise. Then I can see how they work :)
> >
> > At Apache we aren't alone. If we couldn't find any doc via above, then
> > we have Apache Incubating Experts [1]. They're here and are experts for
> > such situations. I can ask them for any clues.
> >
> > But firstly let list what are problems: (I added following which I think
> > summarizes them via reading all of this thread)
> >
> > 1) It seems JIRA causes overhead works while makes it harder to new
> > contributors to file an issue.
> > 2) We don't have a document about how to manage a project using Apache
> > INFRA with these properties: has a lot of monthly revolutionary changes
> > and issues. needs several different contribution expertise e.g. C++,
> > Scala, Python and etc. has a lot of concurrent committers working on
> > different aspects and so may have no time to review others.
> > contributions have different skill levels but their management is flat
> > and not modular.
> >
> > @dev could you please update/delete or add to these if is needed? then
> > when completed, I can research or discuss them with experts mentioned :)
> >
> > Thanks in advance!
> >
> > [1] https://projects.apache.org/committee.html?incubator
> >
>

Re: Vote to stop using JIRA

[Marco de Abreu]

Thanks a lot, this sounds like a good start. We definitely do not want to
re-invent the wheel - if there's some setup we can copy, I'd love to do
that as well!

Something we need is the possibility to have projects with subtasks and the
ability for any contributor (not committer) to contribute to these
projects. This could be adding tasks, changing the state of a task, maybe
even labelling and other things you usually do if you work on systems like
a Kanban-board. We want to give contributors the possibility to manage a
project entirely on their own without much involvement of committers.

-Marco

On Sat, Jun 9, 2018 at 5:32 PM Yasser Zamani 
wrote:

>
>
> On 6/9/2018 5:01 PM, Marco de Abreu wrote:
> > Would you mind creating a proposal document at
> > [1], describing what you would have in mind and how project planning,
> > -management, development, planning, third-party-engagements and other
> > things you can think of would look like then?
>
> Yes of course. However, I think we don't have to reinvent the wheel. I'm
> almost sure there are projects in Apache (either incubating or not)
> which have similar general properties like MXNet. e.g. from Apache
> reports, we can see which incubating (or not) project has a lot of
> monthly revolutionary changes or issues while needs several different
> contribution expertise. Then I can see how they work :)
>
> At Apache we aren't alone. If we couldn't find any doc via above, then
> we have Apache Incubating Experts [1]. They're here and are experts for
> such situations. I can ask them for any clues.
>
> But firstly let list what are problems: (I added following which I think
> summarizes them via reading all of this thread)
>
> 1) It seems JIRA causes overhead works while makes it harder to new
> contributors to file an issue.
> 2) We don't have a document about how to manage a project using Apache
> INFRA with these properties: has a lot of monthly revolutionary changes
> and issues. needs several different contribution expertise e.g. C++,
> Scala, Python and etc. has a lot of concurrent committers working on
> different aspects and so may have no time to review others.
> contributions have different skill levels but their management is flat
> and not modular.
>
> @dev could you please update/delete or add to these if is needed? then
> when completed, I can research or discuss them with experts mentioned :)
>
> Thanks in advance!
>
> [1] https://projects.apache.org/committee.html?incubator
>

Re: Vote to stop using JIRA

[Yasser Zamani]

On 6/9/2018 5:01 PM, Marco de Abreu wrote:
> Would you mind creating a proposal document at
> [1], describing what you would have in mind and how project planning,
> -management, development, planning, third-party-engagements and other
> things you can think of would look like then?

Yes of course. However, I think we don't have to reinvent the wheel. I'm
almost sure there are projects in Apache (either incubating or not)
which have similar general properties like MXNet. e.g. from Apache
reports, we can see which incubating (or not) project has a lot of
monthly revolutionary changes or issues while needs several different
contribution expertise. Then I can see how they work :)

At Apache we aren't alone. If we couldn't find any doc via above, then
we have Apache Incubating Experts [1]. They're here and are experts for
such situations. I can ask them for any clues.

But firstly let list what are problems: (I added following which I think
summarizes them via reading all of this thread)

1) It seems JIRA causes overhead works while makes it harder to new
contributors to file an issue.
2) We don't have a document about how to manage a project using Apache
INFRA with these properties: has a lot of monthly revolutionary changes
and issues. needs several different contribution expertise e.g. C++,
Scala, Python and etc. has a lot of concurrent committers working on
different aspects and so may have no time to review others.
contributions have different skill levels but their management is flat
and not modular.

@dev could you please update/delete or add to these if is needed? then
when completed, I can research or discuss them with experts mentioned :)

Thanks in advance!

[1] https://projects.apache.org/committee.html?incubator

Re: Vote to stop using JIRA

[Marco de Abreu]

Hello Yasser,
welcome to MXNet then! I'm glad you are enjoying it :)

Thanks a lot for the offer! Would you mind creating a proposal document at
[1], describing what you would have in mind and how project planning,
-management, development, planning, third-party-engagements and other
things you can think of would look like then? Please let us know if you
need permissions to edit the wiki.

Best regards,
Marco

[1]: https://cwiki.apache.org/confluence/display/MXNET/Design+Proposals

On Sat, Jun 9, 2018 at 12:56 PM Yasser Zamani 
wrote:

>
>
> On 6/9/2018 12:43 PM, Marco de Abreu wrote:
> > I think the big problem is that we have nobody who maintains JIRA
> properly.
> > If we had a dedicated person who owns that system, I'm sure we could
> excell
> > at it's usage and it would provide better value. About the plugins, I
> have
> > to agree that we can just request assistance from Apache INFRA - that's
> > what they are here for.
> >
> > I'd like to invite any non-committer to step up and help us with that
> > system. We are able to grant any permissions even to non-committers, so
> > that should not be a problem.
>
> I'm already an Apache Struts committer [1] having experience with JIRA,
> Jenkins, Travis and etc but non-committer here. Recently I fell in love
> with mxnet. I mean I'm currently almost a newbie (this week I finished
> chapter 1 of [2] and also were able to build mxnet from source).
> Currently I continue studying at [2] while tracking here dev list and
> JIRA. I'm planning to start fixing small issues as soon as I could :)
>
> So according to above introduction to me, if you think I can be helpful
> then I will be very happy to help. It's my honor and very good
> opportunity to get involved and learn mxnet :)
>
> Thanks in advance!
>
> [1] http://struts.apache.org/volunteers.html#committers
> [2] https://gluon.mxnet.io/
>

Re: Vote to stop using JIRA

[Yasser Zamani]

On 6/9/2018 12:43 PM, Marco de Abreu wrote:
> I think the big problem is that we have nobody who maintains JIRA properly.
> If we had a dedicated person who owns that system, I'm sure we could excell
> at it's usage and it would provide better value. About the plugins, I have
> to agree that we can just request assistance from Apache INFRA - that's
> what they are here for.
> 
> I'd like to invite any non-committer to step up and help us with that
> system. We are able to grant any permissions even to non-committers, so
> that should not be a problem.

I'm already an Apache Struts committer [1] having experience with JIRA,
Jenkins, Travis and etc but non-committer here. Recently I fell in love
with mxnet. I mean I'm currently almost a newbie (this week I finished
chapter 1 of [2] and also were able to build mxnet from source).
Currently I continue studying at [2] while tracking here dev list and
JIRA. I'm planning to start fixing small issues as soon as I could :)

So according to above introduction to me, if you think I can be helpful
then I will be very happy to help. It's my honor and very good
opportunity to get involved and learn mxnet :)

Thanks in advance!

[1] http://struts.apache.org/volunteers.html#committers
[2] https://gluon.mxnet.io/

Re: Vote to stop using JIRA

[Marco de Abreu]

I like the idea, it's similar to the label aaron just introduced. I don't
think there is a need to separate these two. I'd say we use GitHub for high
level things and topics that have not been investigated yet. JIRA would be
for clearly actionable things. Your proposal could be included with these
labels.

-Marco

Pigeon Lucky  schrieb am Sa., 9. Juni 2018, 10:57:

> +0.5
> I think we can separate our JIRA issue to two groups, one is a simpler
> group to the new who wants to contribute to MXNET but haven't become a
> contributer yet and will be published in the github issue, another for only
> contributer to access, which of course will have some more harder to answer
> or codding questions and will be published at JIRA.
> For example, the simple one can be documents, bug fix or new ideas, the the
> harder one can be new idea implementation.
>
> On 9 Jun 2018 4:13 p.m., "Marco de Abreu" 
> wrote:
>
> > Hi,
> >
> > thanks for your feedback!
> >
> > I think the big problem is that we have nobody who maintains JIRA
> properly.
> > If we had a dedicated person who owns that system, I'm sure we could
> excell
> > at it's usage and it would provide better value. About the plugins, I
> have
> > to agree that we can just request assistance from Apache INFRA - that's
> > what they are here for.
> >
> > Eric, we can't use GitHub the way you think you can. All features are
> > restricted to committers only. Nobody who's not a committer can change a
> > project plan, add tasks, change the status or do anything at all. JIRA -
> > with proper configuration - would allow this. I think we have to focus on
> > getting JIRA to work with the use cases we have and then we can revisit
> it.
> > But so far, unfortunately there has been nobody to step up.
> >
> > I'd like to invite any non-committer to step up and help us with that
> > system. We are able to grant any permissions even to non-committers, so
> > that should not be a problem.
> >
> > Best regards,
> > Marco
> >
> > Yasser Zamani  schrieb am Sa., 9. Juni 2018,
> > 07:36:
> >
> > >
> > >
> > > On 6/8/2018 9:57 PM, Eric Xie wrote:
> > > > Hi,
> > > >
> > > > Since all of MXNet's development happens on Github, I think it's
> > > sufficient to use Github Issues and Github Projects for tracking. There
> > are
> > > also many other plugins you can add to Github if issues and projects
> are
> > > not enough.
> > > >
> > > > It's very easy to cross reference PRs and issues for tracking. In
> > > comparison, JIRA is an outdated system with very little features and no
> > > integration with Github. I think using it achieves nothing but
> additional
> > > overhead.
> > >
> > > -1 as I afraid it may violate "Apache Way". Microsoft is going to buy
> > > GitHub. What happens to Apache histories if one day he decided to drop
> > > GitHub data including Apache projects histories?! or decided to change
> > > usage license or payment?! and etc!
> > >
> > > However, I found it seems was legally OK in 2016 [1] BUT I think we
> must
> > > ask again also "general@incubator and/or community@apache and/or board
> > > rather than at legal-discuss" [1]. (at least informs them about the
> > > state of the art).
> > >
> > > I personally prefer to stick together with Apache INFRA Team and ask
> > > them to automate any overhead work instead. e.g. they already have a
> > > nice JIRA and GitHub PR connection [2].
> > >
> > > Regards.
> > >
> > > [1]
> > >
> > > https://lists.apache.org/thread.html/2890619eb1ca049f057c95a3378efc
> > 7be5d54d646c693d2e2560c103@%3Clegal-discuss.apache.org%3E
> > > [2]
> > >
> > > https://github.com/openzipkin/openzipkin.github.io/issues/
> > 51#issuecomment-250877803
> > >  "For our project, a PR should have a corresponding JIRA issue -- we
> use
> > > GH PR templates to tell contributors what to do . For issue tracking we
> > > use Apache JIRA. Apache has webhooks in Github that detects the "JIRA
> > > token" in a PR title (for example, the token for this PR is CB-11860
> and
> > > this makes any GH comments in the PR reflect back to the JIRA issue
> (but
> > > not vice versa), and it is also sent to a project mailing list as
> well."
> > >
> >
>

Re: Vote to stop using JIRA

[Pigeon Lucky]

+0.5
I think we can separate our JIRA issue to two groups, one is a simpler
group to the new who wants to contribute to MXNET but haven't become a
contributer yet and will be published in the github issue, another for only
contributer to access, which of course will have some more harder to answer
or codding questions and will be published at JIRA.
For example, the simple one can be documents, bug fix or new ideas, the the
harder one can be new idea implementation.

On 9 Jun 2018 4:13 p.m., "Marco de Abreu" 
wrote:

> Hi,
>
> thanks for your feedback!
>
> I think the big problem is that we have nobody who maintains JIRA properly.
> If we had a dedicated person who owns that system, I'm sure we could excell
> at it's usage and it would provide better value. About the plugins, I have
> to agree that we can just request assistance from Apache INFRA - that's
> what they are here for.
>
> Eric, we can't use GitHub the way you think you can. All features are
> restricted to committers only. Nobody who's not a committer can change a
> project plan, add tasks, change the status or do anything at all. JIRA -
> with proper configuration - would allow this. I think we have to focus on
> getting JIRA to work with the use cases we have and then we can revisit it.
> But so far, unfortunately there has been nobody to step up.
>
> I'd like to invite any non-committer to step up and help us with that
> system. We are able to grant any permissions even to non-committers, so
> that should not be a problem.
>
> Best regards,
> Marco
>
> Yasser Zamani  schrieb am Sa., 9. Juni 2018,
> 07:36:
>
> >
> >
> > On 6/8/2018 9:57 PM, Eric Xie wrote:
> > > Hi,
> > >
> > > Since all of MXNet's development happens on Github, I think it's
> > sufficient to use Github Issues and Github Projects for tracking. There
> are
> > also many other plugins you can add to Github if issues and projects are
> > not enough.
> > >
> > > It's very easy to cross reference PRs and issues for tracking. In
> > comparison, JIRA is an outdated system with very little features and no
> > integration with Github. I think using it achieves nothing but additional
> > overhead.
> >
> > -1 as I afraid it may violate "Apache Way". Microsoft is going to buy
> > GitHub. What happens to Apache histories if one day he decided to drop
> > GitHub data including Apache projects histories?! or decided to change
> > usage license or payment?! and etc!
> >
> > However, I found it seems was legally OK in 2016 [1] BUT I think we must
> > ask again also "general@incubator and/or community@apache and/or board
> > rather than at legal-discuss" [1]. (at least informs them about the
> > state of the art).
> >
> > I personally prefer to stick together with Apache INFRA Team and ask
> > them to automate any overhead work instead. e.g. they already have a
> > nice JIRA and GitHub PR connection [2].
> >
> > Regards.
> >
> > [1]
> >
> > https://lists.apache.org/thread.html/2890619eb1ca049f057c95a3378efc
> 7be5d54d646c693d2e2560c103@%3Clegal-discuss.apache.org%3E
> > [2]
> >
> > https://github.com/openzipkin/openzipkin.github.io/issues/
> 51#issuecomment-250877803
> >  "For our project, a PR should have a corresponding JIRA issue -- we use
> > GH PR templates to tell contributors what to do . For issue tracking we
> > use Apache JIRA. Apache has webhooks in Github that detects the "JIRA
> > token" in a PR title (for example, the token for this PR is CB-11860 and
> > this makes any GH comments in the PR reflect back to the JIRA issue (but
> > not vice versa), and it is also sent to a project mailing list as well."
> >
>

Re: Vote to stop using JIRA

[Marco de Abreu]

Hi,

thanks for your feedback!

I think the big problem is that we have nobody who maintains JIRA properly.
If we had a dedicated person who owns that system, I'm sure we could excell
at it's usage and it would provide better value. About the plugins, I have
to agree that we can just request assistance from Apache INFRA - that's
what they are here for.

Eric, we can't use GitHub the way you think you can. All features are
restricted to committers only. Nobody who's not a committer can change a
project plan, add tasks, change the status or do anything at all. JIRA -
with proper configuration - would allow this. I think we have to focus on
getting JIRA to work with the use cases we have and then we can revisit it.
But so far, unfortunately there has been nobody to step up.

I'd like to invite any non-committer to step up and help us with that
system. We are able to grant any permissions even to non-committers, so
that should not be a problem.

Best regards,
Marco

Yasser Zamani  schrieb am Sa., 9. Juni 2018, 07:36:

>
>
> On 6/8/2018 9:57 PM, Eric Xie wrote:
> > Hi,
> >
> > Since all of MXNet's development happens on Github, I think it's
> sufficient to use Github Issues and Github Projects for tracking. There are
> also many other plugins you can add to Github if issues and projects are
> not enough.
> >
> > It's very easy to cross reference PRs and issues for tracking. In
> comparison, JIRA is an outdated system with very little features and no
> integration with Github. I think using it achieves nothing but additional
> overhead.
>
> -1 as I afraid it may violate "Apache Way". Microsoft is going to buy
> GitHub. What happens to Apache histories if one day he decided to drop
> GitHub data including Apache projects histories?! or decided to change
> usage license or payment?! and etc!
>
> However, I found it seems was legally OK in 2016 [1] BUT I think we must
> ask again also "general@incubator and/or community@apache and/or board
> rather than at legal-discuss" [1]. (at least informs them about the
> state of the art).
>
> I personally prefer to stick together with Apache INFRA Team and ask
> them to automate any overhead work instead. e.g. they already have a
> nice JIRA and GitHub PR connection [2].
>
> Regards.
>
> [1]
>
> https://lists.apache.org/thread.html/2890619eb1ca049f057c95a3378efc7be5d54d646c693d2e2560c103@%3Clegal-discuss.apache.org%3E
> [2]
>
> https://github.com/openzipkin/openzipkin.github.io/issues/51#issuecomment-250877803
>  "For our project, a PR should have a corresponding JIRA issue -- we use
> GH PR templates to tell contributors what to do . For issue tracking we
> use Apache JIRA. Apache has webhooks in Github that detects the "JIRA
> token" in a PR title (for example, the token for this PR is CB-11860 and
> this makes any GH comments in the PR reflect back to the JIRA issue (but
> not vice versa), and it is also sent to a project mailing list as well."
>

Re: Vote to stop using JIRA

[Yasser Zamani]

On 6/8/2018 9:57 PM, Eric Xie wrote:
> Hi,
> 
> Since all of MXNet's development happens on Github, I think it's sufficient 
> to use Github Issues and Github Projects for tracking. There are also many 
> other plugins you can add to Github if issues and projects are not enough.
> 
> It's very easy to cross reference PRs and issues for tracking. In comparison, 
> JIRA is an outdated system with very little features and no integration with 
> Github. I think using it achieves nothing but additional overhead.

-1 as I afraid it may violate "Apache Way". Microsoft is going to buy
GitHub. What happens to Apache histories if one day he decided to drop
GitHub data including Apache projects histories?! or decided to change
usage license or payment?! and etc!

However, I found it seems was legally OK in 2016 [1] BUT I think we must
ask again also "general@incubator and/or community@apache and/or board
rather than at legal-discuss" [1]. (at least informs them about the
state of the art).

I personally prefer to stick together with Apache INFRA Team and ask
them to automate any overhead work instead. e.g. they already have a
nice JIRA and GitHub PR connection [2].

Regards.

[1]
https://lists.apache.org/thread.html/2890619eb1ca049f057c95a3378efc7be5d54d646c693d2e2560c103@%3Clegal-discuss.apache.org%3E
[2]
https://github.com/openzipkin/openzipkin.github.io/issues/51#issuecomment-250877803
 "For our project, a PR should have a corresponding JIRA issue -- we use
GH PR templates to tell contributors what to do . For issue tracking we
use Apache JIRA. Apache has webhooks in Github that detects the "JIRA
token" in a PR title (for example, the token for this PR is CB-11860 and
this makes any GH comments in the PR reflect back to the JIRA issue (but
not vice versa), and it is also sent to a project mailing list as well."

Re: Vote to stop using JIRA

[Jun Wu]

+1

I have used Jira for a few years. At the time, it had much richer
customized features, at the cost of raising a specialized team developing
Jira plugins, than what the Jira system has for MXNet. Even so, I'm still
not a big fan of it. The learning curve is quite steep to make the personal
dashboard aligned with the team's. In the open source world, we can neither
afford having dedicated Jira support from a specialized team nor increasing
unnecessary overhead of developers. After using Jira for managing the
development work of MXNet for several months, I don't see any advantages of
using Jira with currently available features over GitHub Projects tracking
system.

On Fri, Jun 8, 2018 at 7:17 PM, Thomas DELTEIL 
wrote:

> +0.5
>
> Thanks Timur for the constructive feedback!
>
> For me the problem is exactly as Anirudh raised, I am not a big fan of it
> but I don't think JIRA has been given a fair shot. The problem lies not so
> much with the tracking platform but rather with the contributors following
> the project management guidelines.
>
> All the best,
>
> Thomas
>
>
> 2018-06-08 17:05 GMT-07:00 Eric Xie :
>
> > Github has many project management tools. Any of them would be a better
> > choice than JIRA.
> >
> > Thanks,
> > Eric
> >
> > On 2018/06/09 00:02:55, Timur Shenkao  wrote:
> > > Hello guys!
> > > Let me add five cents step-by-step. Some kind of "external viewpoint"
> (I
> > > don't work in Amazon or Intel).
> > > 1) Thanks a lot of for interesting product / framework like MXNet.
> > > Currently, I use pretty standard DL stack: Keras + TF and some other
> less
> > > popular libraries. But I am not completely satisfied so I am looking
> for
> > > something new for my upcoming projects. So, I "investigate" MXNet now.
> > >
> > > 2)* I completely agree with Naveen*.
> > >
> > > 3) If you really want to see wide adoption of MXNet (like Spark, Kafka,
> > > Flink, etc.), then tasks should be documented in some task tracker.
> > > In this case everyone would be able to see the progress of the project,
> > > understand which features, bug fixes are included into the next
> release,
> > > intended to appear in near future. Developers, contributors, committers
> > can
> > > see the progress, the cadence of the project. Links to docs, Github
> PRs,
> > > roadmaps, proposals, build results, other JIRAs are present in a JIRA
> > > ticket so it's easy to navigate for everyone.
> > > Github is suitable for code review and management. But it can't
> > substitute
> > > tracker system. Even small team will have hundreds of PRs, issues
> pretty
> > > soon and chaos arises. Besides, there is no much fun (for "external"
> > user)
> > > in jumping from one Github PR to another trying to understand why &
> when
> > &
> > > in which commit something appeared.
> > > I understand that MXNet was promoted into Apache incubator to enlarge
> > > community, build ecosystem around it and for some other "commercial
> > > interests". Without clear vision and understanding of project's status
> &
> > > future, nobody will take MXNet into production or build MXNetT
> "plugin".
> > >
> > > 4)  "*There are 900+ issues, that once in a while gets closed without
> any
> > > reason has happened already once*". It also happens with other
> > Github-based
> > > projects. For example, Presto committers go through list of issues once
> > or
> > > twice a year. And close vast majority of them with resolutions like
> > "Won't
> > > fix", "I don't like it", etc.
> > >
> > > 5) JIRA is very configurable, one does not have to jump from board to
> > board
> > > to edit / enter ticket info. I have Apache's JIRA account. And I can
> > read,
> > > add comments & files / patches to tickets, create tickets in some
> > projects.
> > > But privileges can be configured.
> > >
> > >
> > > Timur
> > >
> > > On Fri, Jun 8, 2018 at 10:48 PM, Hen  wrote:
> > >
> > > > Are you saying only committers can make JIRA accounts?
> > > >
> > > > On Fri, Jun 8, 2018 at 2:41 PM Qing Lan  wrote:
> > > >
> > > > > + 0
> > > > > Can we keep this optional? Not totally abandon or support.
> > > > > Pros:
> > > > > I used JIRA to track most of my PRs and can place them together at
> > one
> > > > > place. It also being helpful if we find some issues and group them
> > > > together
> > > > > as one case.
> > > > > Cons:
> > > > > Currently JIRA does not allow someone who is not contributor to
> file
> > an
> > > > > issue which makes first-time contributor hard to submit a PR.
> > > > >
> > > > > Thanks,
> > > > > Qing
> > > > >
> > > > >
> > > > > On 6/8/18, 2:27 PM, "Hao Jin"  wrote:
> > > > >
> > > > > +0.5
> > > > > I'm an SDE working for MXNet Engine team at AWS and I've been
> > using
> > > > > JIRA
> > > > > for nearly every single PR (28 out of 29 PR at this moment) I
> > created
> > > > > since
> > > > > I joined the team 3 months ago. I wouldn't say it's a really
> bad
> > > > > experience, but definitely not good.
> > > > > I do agree 

Re: Vote to stop using JIRA

[Thomas DELTEIL]

+0.5

Thanks Timur for the constructive feedback!

For me the problem is exactly as Anirudh raised, I am not a big fan of it
but I don't think JIRA has been given a fair shot. The problem lies not so
much with the tracking platform but rather with the contributors following
the project management guidelines.

All the best,

Thomas


2018-06-08 17:05 GMT-07:00 Eric Xie :

> Github has many project management tools. Any of them would be a better
> choice than JIRA.
>
> Thanks,
> Eric
>
> On 2018/06/09 00:02:55, Timur Shenkao  wrote:
> > Hello guys!
> > Let me add five cents step-by-step. Some kind of "external viewpoint" (I
> > don't work in Amazon or Intel).
> > 1) Thanks a lot of for interesting product / framework like MXNet.
> > Currently, I use pretty standard DL stack: Keras + TF and some other less
> > popular libraries. But I am not completely satisfied so I am looking for
> > something new for my upcoming projects. So, I "investigate" MXNet now.
> >
> > 2)* I completely agree with Naveen*.
> >
> > 3) If you really want to see wide adoption of MXNet (like Spark, Kafka,
> > Flink, etc.), then tasks should be documented in some task tracker.
> > In this case everyone would be able to see the progress of the project,
> > understand which features, bug fixes are included into the next release,
> > intended to appear in near future. Developers, contributors, committers
> can
> > see the progress, the cadence of the project. Links to docs, Github PRs,
> > roadmaps, proposals, build results, other JIRAs are present in a JIRA
> > ticket so it's easy to navigate for everyone.
> > Github is suitable for code review and management. But it can't
> substitute
> > tracker system. Even small team will have hundreds of PRs, issues pretty
> > soon and chaos arises. Besides, there is no much fun (for "external"
> user)
> > in jumping from one Github PR to another trying to understand why & when
> &
> > in which commit something appeared.
> > I understand that MXNet was promoted into Apache incubator to enlarge
> > community, build ecosystem around it and for some other "commercial
> > interests". Without clear vision and understanding of project's status &
> > future, nobody will take MXNet into production or build MXNetT "plugin".
> >
> > 4)  "*There are 900+ issues, that once in a while gets closed without any
> > reason has happened already once*". It also happens with other
> Github-based
> > projects. For example, Presto committers go through list of issues once
> or
> > twice a year. And close vast majority of them with resolutions like
> "Won't
> > fix", "I don't like it", etc.
> >
> > 5) JIRA is very configurable, one does not have to jump from board to
> board
> > to edit / enter ticket info. I have Apache's JIRA account. And I can
> read,
> > add comments & files / patches to tickets, create tickets in some
> projects.
> > But privileges can be configured.
> >
> >
> > Timur
> >
> > On Fri, Jun 8, 2018 at 10:48 PM, Hen  wrote:
> >
> > > Are you saying only committers can make JIRA accounts?
> > >
> > > On Fri, Jun 8, 2018 at 2:41 PM Qing Lan  wrote:
> > >
> > > > + 0
> > > > Can we keep this optional? Not totally abandon or support.
> > > > Pros:
> > > > I used JIRA to track most of my PRs and can place them together at
> one
> > > > place. It also being helpful if we find some issues and group them
> > > together
> > > > as one case.
> > > > Cons:
> > > > Currently JIRA does not allow someone who is not contributor to file
> an
> > > > issue which makes first-time contributor hard to submit a PR.
> > > >
> > > > Thanks,
> > > > Qing
> > > >
> > > >
> > > > On 6/8/18, 2:27 PM, "Hao Jin"  wrote:
> > > >
> > > > +0.5
> > > > I'm an SDE working for MXNet Engine team at AWS and I've been
> using
> > > > JIRA
> > > > for nearly every single PR (28 out of 29 PR at this moment) I
> created
> > > > since
> > > > I joined the team 3 months ago. I wouldn't say it's a really bad
> > > > experience, but definitely not good.
> > > > I do agree that we need something like JIRA and extra effort
> other
> > > than
> > > > writing code to manage the project, but the current user
> experience
> > > > with
> > > > JIRA really has room for improvement.
> > > > The more important question for the community is that, is JIRA
> good
> > > for
> > > > attracting and retaining open source contributors? Such a user
> > > > experience
> > > > of JIRA could drive contributors away if we're really enforcing
> it.
> > > > In conclusion, I think the usage of JIRA should be of one's or
> team's
> > > > own
> > > > choice, if you do have the need to manage some development
> process
> > > > (like
> > > > our team), just continue to use it, but we should no longer
> enforce
> > > or
> > > > persuade anyone to use it.
> > > > I'm also attaching a typical workflow of mine using JIRA with
> sprint
> > > > management and story point tracking for a single task, I think
> > > > 

Re: Vote to stop using JIRA

[Eric Xie]

Github has many project management tools. Any of them would be a better choice 
than JIRA.

Thanks,
Eric

On 2018/06/09 00:02:55, Timur Shenkao  wrote: 
> Hello guys!
> Let me add five cents step-by-step. Some kind of "external viewpoint" (I
> don't work in Amazon or Intel).
> 1) Thanks a lot of for interesting product / framework like MXNet.
> Currently, I use pretty standard DL stack: Keras + TF and some other less
> popular libraries. But I am not completely satisfied so I am looking for
> something new for my upcoming projects. So, I "investigate" MXNet now.
> 
> 2)* I completely agree with Naveen*.
> 
> 3) If you really want to see wide adoption of MXNet (like Spark, Kafka,
> Flink, etc.), then tasks should be documented in some task tracker.
> In this case everyone would be able to see the progress of the project,
> understand which features, bug fixes are included into the next release,
> intended to appear in near future. Developers, contributors, committers can
> see the progress, the cadence of the project. Links to docs, Github PRs,
> roadmaps, proposals, build results, other JIRAs are present in a JIRA
> ticket so it's easy to navigate for everyone.
> Github is suitable for code review and management. But it can't substitute
> tracker system. Even small team will have hundreds of PRs, issues pretty
> soon and chaos arises. Besides, there is no much fun (for "external" user)
> in jumping from one Github PR to another trying to understand why & when &
> in which commit something appeared.
> I understand that MXNet was promoted into Apache incubator to enlarge
> community, build ecosystem around it and for some other "commercial
> interests". Without clear vision and understanding of project's status &
> future, nobody will take MXNet into production or build MXNetT "plugin".
> 
> 4)  "*There are 900+ issues, that once in a while gets closed without any
> reason has happened already once*". It also happens with other Github-based
> projects. For example, Presto committers go through list of issues once or
> twice a year. And close vast majority of them with resolutions like "Won't
> fix", "I don't like it", etc.
> 
> 5) JIRA is very configurable, one does not have to jump from board to board
> to edit / enter ticket info. I have Apache's JIRA account. And I can read,
> add comments & files / patches to tickets, create tickets in some projects.
> But privileges can be configured.
> 
> 
> Timur
> 
> On Fri, Jun 8, 2018 at 10:48 PM, Hen  wrote:
> 
> > Are you saying only committers can make JIRA accounts?
> >
> > On Fri, Jun 8, 2018 at 2:41 PM Qing Lan  wrote:
> >
> > > + 0
> > > Can we keep this optional? Not totally abandon or support.
> > > Pros:
> > > I used JIRA to track most of my PRs and can place them together at one
> > > place. It also being helpful if we find some issues and group them
> > together
> > > as one case.
> > > Cons:
> > > Currently JIRA does not allow someone who is not contributor to file an
> > > issue which makes first-time contributor hard to submit a PR.
> > >
> > > Thanks,
> > > Qing
> > >
> > >
> > > On 6/8/18, 2:27 PM, "Hao Jin"  wrote:
> > >
> > > +0.5
> > > I'm an SDE working for MXNet Engine team at AWS and I've been using
> > > JIRA
> > > for nearly every single PR (28 out of 29 PR at this moment) I created
> > > since
> > > I joined the team 3 months ago. I wouldn't say it's a really bad
> > > experience, but definitely not good.
> > > I do agree that we need something like JIRA and extra effort other
> > than
> > > writing code to manage the project, but the current user experience
> > > with
> > > JIRA really has room for improvement.
> > > The more important question for the community is that, is JIRA good
> > for
> > > attracting and retaining open source contributors? Such a user
> > > experience
> > > of JIRA could drive contributors away if we're really enforcing it.
> > > In conclusion, I think the usage of JIRA should be of one's or team's
> > > own
> > > choice, if you do have the need to manage some development process
> > > (like
> > > our team), just continue to use it, but we should no longer enforce
> > or
> > > persuade anyone to use it.
> > > I'm also attaching a typical workflow of mine using JIRA with sprint
> > > management and story point tracking for a single task, I think
> > > everyone who
> > > has used JIRA so far would share part of my experience.
> > > Thanks,
> > > Hao
> > >
> > > Appendix: what I need to do when I'm working on a task with JIRA:
> > > 1. Before I start working on something:
> > > 1) create a JIRA ticket for that, choose the correct type and
> > > define a
> > > proper name for it
> > > 2) go to backlog page to add it to a sprint if you want to use
> > the
> > > sprint management.
> > > 3) go to sprint management page to assign story point value if
> > you
> > > need
> > > the functionality (we 

Re: Vote to stop using JIRA

[Timur Shenkao]

Hello guys!
Let me add five cents step-by-step. Some kind of "external viewpoint" (I
don't work in Amazon or Intel).
1) Thanks a lot of for interesting product / framework like MXNet.
Currently, I use pretty standard DL stack: Keras + TF and some other less
popular libraries. But I am not completely satisfied so I am looking for
something new for my upcoming projects. So, I "investigate" MXNet now.

2)* I completely agree with Naveen*.

3) If you really want to see wide adoption of MXNet (like Spark, Kafka,
Flink, etc.), then tasks should be documented in some task tracker.
In this case everyone would be able to see the progress of the project,
understand which features, bug fixes are included into the next release,
intended to appear in near future. Developers, contributors, committers can
see the progress, the cadence of the project. Links to docs, Github PRs,
roadmaps, proposals, build results, other JIRAs are present in a JIRA
ticket so it's easy to navigate for everyone.
Github is suitable for code review and management. But it can't substitute
tracker system. Even small team will have hundreds of PRs, issues pretty
soon and chaos arises. Besides, there is no much fun (for "external" user)
in jumping from one Github PR to another trying to understand why & when &
in which commit something appeared.
I understand that MXNet was promoted into Apache incubator to enlarge
community, build ecosystem around it and for some other "commercial
interests". Without clear vision and understanding of project's status &
future, nobody will take MXNet into production or build MXNetT "plugin".

4)  "*There are 900+ issues, that once in a while gets closed without any
reason has happened already once*". It also happens with other Github-based
projects. For example, Presto committers go through list of issues once or
twice a year. And close vast majority of them with resolutions like "Won't
fix", "I don't like it", etc.

5) JIRA is very configurable, one does not have to jump from board to board
to edit / enter ticket info. I have Apache's JIRA account. And I can read,
add comments & files / patches to tickets, create tickets in some projects.
But privileges can be configured.


Timur

On Fri, Jun 8, 2018 at 10:48 PM, Hen  wrote:

> Are you saying only committers can make JIRA accounts?
>
> On Fri, Jun 8, 2018 at 2:41 PM Qing Lan  wrote:
>
> > + 0
> > Can we keep this optional? Not totally abandon or support.
> > Pros:
> > I used JIRA to track most of my PRs and can place them together at one
> > place. It also being helpful if we find some issues and group them
> together
> > as one case.
> > Cons:
> > Currently JIRA does not allow someone who is not contributor to file an
> > issue which makes first-time contributor hard to submit a PR.
> >
> > Thanks,
> > Qing
> >
> >
> > On 6/8/18, 2:27 PM, "Hao Jin"  wrote:
> >
> > +0.5
> > I'm an SDE working for MXNet Engine team at AWS and I've been using
> > JIRA
> > for nearly every single PR (28 out of 29 PR at this moment) I created
> > since
> > I joined the team 3 months ago. I wouldn't say it's a really bad
> > experience, but definitely not good.
> > I do agree that we need something like JIRA and extra effort other
> than
> > writing code to manage the project, but the current user experience
> > with
> > JIRA really has room for improvement.
> > The more important question for the community is that, is JIRA good
> for
> > attracting and retaining open source contributors? Such a user
> > experience
> > of JIRA could drive contributors away if we're really enforcing it.
> > In conclusion, I think the usage of JIRA should be of one's or team's
> > own
> > choice, if you do have the need to manage some development process
> > (like
> > our team), just continue to use it, but we should no longer enforce
> or
> > persuade anyone to use it.
> > I'm also attaching a typical workflow of mine using JIRA with sprint
> > management and story point tracking for a single task, I think
> > everyone who
> > has used JIRA so far would share part of my experience.
> > Thanks,
> > Hao
> >
> > Appendix: what I need to do when I'm working on a task with JIRA:
> > 1. Before I start working on something:
> > 1) create a JIRA ticket for that, choose the correct type and
> > define a
> > proper name for it
> > 2) go to backlog page to add it to a sprint if you want to use
> the
> > sprint management.
> > 3) go to sprint management page to assign story point value if
> you
> > need
> > the functionality (we recently started doing that)
> > 2. When I start working on the task:
> > 1) dig my ticket up (on the sprint page or backlog page or search
> > for
> > it)
> > 2) click "open and start progress" to move it to "IN PROGRESS"
> > phase.
> > 3. When I finish the code, for every new PR I'll have to:
> > 1) dig my ticket up
> > 2) 

Re: Vote to stop using JIRA

[Hen]

Are you saying only committers can make JIRA accounts?

On Fri, Jun 8, 2018 at 2:41 PM Qing Lan  wrote:

> + 0
> Can we keep this optional? Not totally abandon or support.
> Pros:
> I used JIRA to track most of my PRs and can place them together at one
> place. It also being helpful if we find some issues and group them together
> as one case.
> Cons:
> Currently JIRA does not allow someone who is not contributor to file an
> issue which makes first-time contributor hard to submit a PR.
>
> Thanks,
> Qing
>
>
> On 6/8/18, 2:27 PM, "Hao Jin"  wrote:
>
> +0.5
> I'm an SDE working for MXNet Engine team at AWS and I've been using
> JIRA
> for nearly every single PR (28 out of 29 PR at this moment) I created
> since
> I joined the team 3 months ago. I wouldn't say it's a really bad
> experience, but definitely not good.
> I do agree that we need something like JIRA and extra effort other than
> writing code to manage the project, but the current user experience
> with
> JIRA really has room for improvement.
> The more important question for the community is that, is JIRA good for
> attracting and retaining open source contributors? Such a user
> experience
> of JIRA could drive contributors away if we're really enforcing it.
> In conclusion, I think the usage of JIRA should be of one's or team's
> own
> choice, if you do have the need to manage some development process
> (like
> our team), just continue to use it, but we should no longer enforce or
> persuade anyone to use it.
> I'm also attaching a typical workflow of mine using JIRA with sprint
> management and story point tracking for a single task, I think
> everyone who
> has used JIRA so far would share part of my experience.
> Thanks,
> Hao
>
> Appendix: what I need to do when I'm working on a task with JIRA:
> 1. Before I start working on something:
> 1) create a JIRA ticket for that, choose the correct type and
> define a
> proper name for it
> 2) go to backlog page to add it to a sprint if you want to use the
> sprint management.
> 3) go to sprint management page to assign story point value if you
> need
> the functionality (we recently started doing that)
> 2. When I start working on the task:
> 1) dig my ticket up (on the sprint page or backlog page or search
> for
> it)
> 2) click "open and start progress" to move it to "IN PROGRESS"
> phase.
> 3. When I finish the code, for every new PR I'll have to:
> 1) dig my ticket up
> 2) copy the ticket number so that I can add it to the PR title
> 3) an extra click to move the ticket to REVIEW phase
> 4) create a PR on github, paste the "MXNET-xxx" I just copied
> inside an
> extra pair of square brackets "[]"
> 5) still need to refer the related github issue in the PR if I'm
> solving one of them
> 4. For every code review or comment I receive on the new PR:
> 1) the JIRA bot logs 10 mins on the ticket no matter what kind of
> comment it is
> 2) JIRA sends me an email for every single one of such logs (so if
> you
> receive 10 code review comments in a single code review you get 10
> emails,
> my highest record was 17, while github would bundle all of them in
> only 1
> mail)
> 5. After the PR is merged I get an email from JIRA saying this is
> merged
> (for the bot, merge is like another comment on the PR) but I still
> have to:
> 1) dig my ticket up
> 2) manually move it to DONE phase (bot does not do that
> automatically).
> 6. The task is considered finished at this point, but any new comments
> on
> the PR will trigger the bot once again to log 10 mins on your ticket
> together with another email coming to your mailbox, while github is
> already
> sending an email for that.
>
> On Fri, Jun 8, 2018 at 2:23 PM, Naveen Swamy 
> wrote:
>
> > Eric/Mu/Tianqi,
> >
> > A couple of contributors  have used JIRA for the Scala project --
> this is
> > the first time, so there is some learning for us, We started off
> with a
> > design proposal, followed by a call for contribution. We kept our
> progress
> > open on the dev list and we found one contributor to help us during
> > debugging/testing/maven package creation and also one of them is
> working on
> > the Memory allocation issue in Scala not as a part of their day job;
> This
> > is where I find value in managing the project features on JIRA,
> designs on
> > the public wiki, etc.,. I am not claiming that this is perfect, this
> is a
> > WIP and as a community we should give it a chance and try it out.
> >
> > I don't think most of us here have even looked at JIRA.
> >
> > P.S: I am traveling, my response will be delayed.
> >
> > -Naveen
> >
> >
> > On Fri, Jun 8, 2018 at 12:34 PM, Anirudh 
> wrote:
> 

Re: Vote to stop using JIRA

[Qing Lan]

+ 0
Can we keep this optional? Not totally abandon or support. 
Pros:
I used JIRA to track most of my PRs and can place them together at one place. 
It also being helpful if we find some issues and group them together as one 
case. 
Cons:
Currently JIRA does not allow someone who is not contributor to file an issue 
which makes first-time contributor hard to submit a PR.

Thanks,
Qing


On 6/8/18, 2:27 PM, "Hao Jin"  wrote:

+0.5
I'm an SDE working for MXNet Engine team at AWS and I've been using JIRA
for nearly every single PR (28 out of 29 PR at this moment) I created since
I joined the team 3 months ago. I wouldn't say it's a really bad
experience, but definitely not good.
I do agree that we need something like JIRA and extra effort other than
writing code to manage the project, but the current user experience with
JIRA really has room for improvement.
The more important question for the community is that, is JIRA good for
attracting and retaining open source contributors? Such a user experience
of JIRA could drive contributors away if we're really enforcing it.
In conclusion, I think the usage of JIRA should be of one's or team's own
choice, if you do have the need to manage some development process (like
our team), just continue to use it, but we should no longer enforce or
persuade anyone to use it.
I'm also attaching a typical workflow of mine using JIRA with sprint
management and story point tracking for a single task, I think everyone who
has used JIRA so far would share part of my experience.
Thanks,
Hao

Appendix: what I need to do when I'm working on a task with JIRA:
1. Before I start working on something:
1) create a JIRA ticket for that, choose the correct type and define a
proper name for it
2) go to backlog page to add it to a sprint if you want to use the
sprint management.
3) go to sprint management page to assign story point value if you need
the functionality (we recently started doing that)
2. When I start working on the task:
1) dig my ticket up (on the sprint page or backlog page or search for
it)
2) click "open and start progress" to move it to "IN PROGRESS" phase.
3. When I finish the code, for every new PR I'll have to:
1) dig my ticket up
2) copy the ticket number so that I can add it to the PR title
3) an extra click to move the ticket to REVIEW phase
4) create a PR on github, paste the "MXNET-xxx" I just copied inside an
extra pair of square brackets "[]"
5) still need to refer the related github issue in the PR if I'm
solving one of them
4. For every code review or comment I receive on the new PR:
1) the JIRA bot logs 10 mins on the ticket no matter what kind of
comment it is
2) JIRA sends me an email for every single one of such logs (so if you
receive 10 code review comments in a single code review you get 10 emails,
my highest record was 17, while github would bundle all of them in only 1
mail)
5. After the PR is merged I get an email from JIRA saying this is merged
(for the bot, merge is like another comment on the PR) but I still have to:
1) dig my ticket up
2) manually move it to DONE phase (bot does not do that automatically).
6. The task is considered finished at this point, but any new comments on
the PR will trigger the bot once again to log 10 mins on your ticket
together with another email coming to your mailbox, while github is already
sending an email for that.

On Fri, Jun 8, 2018 at 2:23 PM, Naveen Swamy  wrote:

> Eric/Mu/Tianqi,
>
> A couple of contributors  have used JIRA for the Scala project -- this is
> the first time, so there is some learning for us, We started off with a
> design proposal, followed by a call for contribution. We kept our progress
> open on the dev list and we found one contributor to help us during
> debugging/testing/maven package creation and also one of them is working 
on
> the Memory allocation issue in Scala not as a part of their day job; This
> is where I find value in managing the project features on JIRA, designs on
> the public wiki, etc.,. I am not claiming that this is perfect, this is a
> WIP and as a community we should give it a chance and try it out.
>
> I don't think most of us here have even looked at JIRA.
>
> P.S: I am traveling, my response will be delayed.
>
> -Naveen
>
>
> On Fri, Jun 8, 2018 at 12:34 PM, Anirudh  wrote:
>
> > Hi,
> >
> > I am not a big fan of JIRA either. But I would like to raise this issue
> of
> > committing to a decision after a VOTE has passed. I saw in PRs that 
there
> > was a disregard for JIRA and ignoring requests on PRs to link to JIRA.
> > Because of this, JIRA was not given a fair 

Re: Vote to stop using JIRA

[Naveen Swamy]

Eric/Mu/Tianqi,

A couple of contributors  have used JIRA for the Scala project -- this is
the first time, so there is some learning for us, We started off with a
design proposal, followed by a call for contribution. We kept our progress
open on the dev list and we found one contributor to help us during
debugging/testing/maven package creation and also one of them is working on
the Memory allocation issue in Scala not as a part of their day job; This
is where I find value in managing the project features on JIRA, designs on
the public wiki, etc.,. I am not claiming that this is perfect, this is a
WIP and as a community we should give it a chance and try it out.

I don't think most of us here have even looked at JIRA.

P.S: I am traveling, my response will be delayed.

-Naveen


On Fri, Jun 8, 2018 at 12:34 PM, Anirudh  wrote:

> Hi,
>
> I am not a big fan of JIRA either. But I would like to raise this issue of
> committing to a decision after a VOTE has passed. I saw in PRs that there
> was a disregard for JIRA and ignoring requests on PRs to link to JIRA.
> Because of this, JIRA was not given a fair chance to be tried out as a
> project management tool and eventually hardly being used. If we don't work
> on this as a community, VOTEs also tend to loose their meaning.
>
> Anirudh
>
>
>
> On Fri, Jun 8, 2018 at 11:00 AM, Eric Xie  wrote:
>
> > I think the number of issues become less of a problem if we label them
> > timely, which is already improving.
> >
> > Thanks,
> > Eric
> >
> > On 2018/06/08 17:55:28, Tianqi Chen  wrote:
> > > I would suggest we have a separate discussion issue about transparency.
> > > First of all, I agree that transparency is important.
> > >
> > > This can be achieved by public roadmaps, RFCs, that do not have
> > > particularly tie to JIRA or github issues. Having a clear guideline on
> > that
> > > would be great, and it is great to see more RFCs in the dev list.
> > >
> > > In terms of issues themselves, I think one problem we are facing is
> > > overflowing amount of issues. One way to minimize this would be to
> > redirect
> > > more questions to forums, and only keep issues that are actionable and
> > > encourage the committers who opens the issue to fix them timely.
> > >
> > > Tianqi
> > >
> > > On Fri, Jun 8, 2018 at 10:35 AM, Naveen Swamy 
> > wrote:
> > >
> > > > -1 (binding)
> > > >
> > > > The very reason why JIRA was suggested so that the project is more
> > open on
> > > > the features that are worked on. There are 900+ issues, that once in
> a
> > > > while gets closed without any reason has happened already once.
> > > > There is already integration with GitHub PRs, please check it out.
> > > >
> > > > Features pop into the code-base without any discussion, they also get
> > > > removed without any discussion. PRs come in when the feature is
> > complete,
> > > > not giving others  opportunity to understand/contribute or have a
> say.
> > > >
> > > > If this project embraces the true Apache spirit and follow successful
> > > > practices we could get lot more people excited about this project.
> Many
> > > > successful Apache projects use JIRA, look at Apache Spark which has
> > 1250+
> > > > contributors and built a community of 500,000 people around the
> world.
> > > >
> > > > -Naveen
> > > >
> > > >
> > > > On Fri, Jun 8, 2018 at 10:27 AM, Eric Xie  wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > Since all of MXNet's development happens on Github, I think it's
> > > > > sufficient to use Github Issues and Github Projects for tracking.
> > There
> > > > are
> > > > > also many other plugins you can add to Github if issues and
> projects
> > are
> > > > > not enough.
> > > > >
> > > > > It's very easy to cross reference PRs and issues for tracking. In
> > > > > comparison, JIRA is an outdated system with very little features
> and
> > no
> > > > > integration with Github. I think using it achieves nothing but
> > additional
> > > > > overhead.
> > > > >
> > > > > Thanks,
> > > > > Eric
> > > > >
> > > >
> > >
> >
>

Re: Vote to stop using JIRA

[Anirudh]

Hi,

I am not a big fan of JIRA either. But I would like to raise this issue of
committing to a decision after a VOTE has passed. I saw in PRs that there
was a disregard for JIRA and ignoring requests on PRs to link to JIRA.
Because of this, JIRA was not given a fair chance to be tried out as a
project management tool and eventually hardly being used. If we don't work
on this as a community, VOTEs also tend to loose their meaning.

Anirudh



On Fri, Jun 8, 2018 at 11:00 AM, Eric Xie  wrote:

> I think the number of issues become less of a problem if we label them
> timely, which is already improving.
>
> Thanks,
> Eric
>
> On 2018/06/08 17:55:28, Tianqi Chen  wrote:
> > I would suggest we have a separate discussion issue about transparency.
> > First of all, I agree that transparency is important.
> >
> > This can be achieved by public roadmaps, RFCs, that do not have
> > particularly tie to JIRA or github issues. Having a clear guideline on
> that
> > would be great, and it is great to see more RFCs in the dev list.
> >
> > In terms of issues themselves, I think one problem we are facing is
> > overflowing amount of issues. One way to minimize this would be to
> redirect
> > more questions to forums, and only keep issues that are actionable and
> > encourage the committers who opens the issue to fix them timely.
> >
> > Tianqi
> >
> > On Fri, Jun 8, 2018 at 10:35 AM, Naveen Swamy 
> wrote:
> >
> > > -1 (binding)
> > >
> > > The very reason why JIRA was suggested so that the project is more
> open on
> > > the features that are worked on. There are 900+ issues, that once in a
> > > while gets closed without any reason has happened already once.
> > > There is already integration with GitHub PRs, please check it out.
> > >
> > > Features pop into the code-base without any discussion, they also get
> > > removed without any discussion. PRs come in when the feature is
> complete,
> > > not giving others  opportunity to understand/contribute or have a say.
> > >
> > > If this project embraces the true Apache spirit and follow successful
> > > practices we could get lot more people excited about this project. Many
> > > successful Apache projects use JIRA, look at Apache Spark which has
> 1250+
> > > contributors and built a community of 500,000 people around the world.
> > >
> > > -Naveen
> > >
> > >
> > > On Fri, Jun 8, 2018 at 10:27 AM, Eric Xie  wrote:
> > >
> > > > Hi,
> > > >
> > > > Since all of MXNet's development happens on Github, I think it's
> > > > sufficient to use Github Issues and Github Projects for tracking.
> There
> > > are
> > > > also many other plugins you can add to Github if issues and projects
> are
> > > > not enough.
> > > >
> > > > It's very easy to cross reference PRs and issues for tracking. In
> > > > comparison, JIRA is an outdated system with very little features and
> no
> > > > integration with Github. I think using it achieves nothing but
> additional
> > > > overhead.
> > > >
> > > > Thanks,
> > > > Eric
> > > >
> > >
> >
>

Re: Vote to stop using JIRA

[Marco de Abreu]

+1

While the intention of JIRA was good, we have proven as a community that we
are not able to use it properly and it's only being a burden. The initial
idea was that it allows us to manage projects publicly, make plans and
allow everybody to engage into these projects by just picking small tasks.

The reality is that everybody is just copy and pasting the PR title into
JIRA, there are no projects with subtasks, tickets are not maintained and
just stay open, there is no labelling in place or anything. In that state,
it does not provide any value. I don't really see how this is going to
change and thus it's better to remove the system altogether.

It's a pity that we as a community were not able to get this to work, but
that's the reality. In the best interest of our contributors, it'd be the
best to remove it again.

Best regards,
Marco

Mu Li  schrieb am Fr., 8. Juni 2018, 19:49:

> Hi Naveen,
>
> Can we clarify that how JIRA improved the project?  One key Apache spirit
> is
> about transparent, but I didn't see the current way we are using JIRA
> improves it. Comparing to Spark, one major problem is that we have 10x less
> active contributors. Even PyTorch is 3x more active (#commits, #LOC
> #contributors) than us. If JIRA makes contributing harder, we should
> consider a better approach.
>
> Best
> Mu
>
> On Fri, Jun 8, 2018 at 10:35 AM, Naveen Swamy  wrote:
>
> > -1 (binding)
> >
> > The very reason why JIRA was suggested so that the project is more open
> on
> > the features that are worked on. There are 900+ issues, that once in a
> > while gets closed without any reason has happened already once.
> > There is already integration with GitHub PRs, please check it out.
> >
> > Features pop into the code-base without any discussion, they also get
> > removed without any discussion. PRs come in when the feature is complete,
> > not giving others  opportunity to understand/contribute or have a say.
> >
> > If this project embraces the true Apache spirit and follow successful
> > practices we could get lot more people excited about this project. Many
> > successful Apache projects use JIRA, look at Apache Spark which has 1250+
> > contributors and built a community of 500,000 people around the world.
> >
> > -Naveen
> >
> >
> > On Fri, Jun 8, 2018 at 10:27 AM, Eric Xie  wrote:
> >
> > > Hi,
> > >
> > > Since all of MXNet's development happens on Github, I think it's
> > > sufficient to use Github Issues and Github Projects for tracking. There
> > are
> > > also many other plugins you can add to Github if issues and projects
> are
> > > not enough.
> > >
> > > It's very easy to cross reference PRs and issues for tracking. In
> > > comparison, JIRA is an outdated system with very little features and no
> > > integration with Github. I think using it achieves nothing but
> additional
> > > overhead.
> > >
> > > Thanks,
> > > Eric
> > >
> >
>

Re: Vote to stop using JIRA

[Tianqi Chen]

I would suggest we have a separate discussion issue about transparency.
First of all, I agree that transparency is important.

This can be achieved by public roadmaps, RFCs, that do not have
particularly tie to JIRA or github issues. Having a clear guideline on that
would be great, and it is great to see more RFCs in the dev list.

In terms of issues themselves, I think one problem we are facing is
overflowing amount of issues. One way to minimize this would be to redirect
more questions to forums, and only keep issues that are actionable and
encourage the committers who opens the issue to fix them timely.

Tianqi

On Fri, Jun 8, 2018 at 10:35 AM, Naveen Swamy  wrote:

> -1 (binding)
>
> The very reason why JIRA was suggested so that the project is more open on
> the features that are worked on. There are 900+ issues, that once in a
> while gets closed without any reason has happened already once.
> There is already integration with GitHub PRs, please check it out.
>
> Features pop into the code-base without any discussion, they also get
> removed without any discussion. PRs come in when the feature is complete,
> not giving others  opportunity to understand/contribute or have a say.
>
> If this project embraces the true Apache spirit and follow successful
> practices we could get lot more people excited about this project. Many
> successful Apache projects use JIRA, look at Apache Spark which has 1250+
> contributors and built a community of 500,000 people around the world.
>
> -Naveen
>
>
> On Fri, Jun 8, 2018 at 10:27 AM, Eric Xie  wrote:
>
> > Hi,
> >
> > Since all of MXNet's development happens on Github, I think it's
> > sufficient to use Github Issues and Github Projects for tracking. There
> are
> > also many other plugins you can add to Github if issues and projects are
> > not enough.
> >
> > It's very easy to cross reference PRs and issues for tracking. In
> > comparison, JIRA is an outdated system with very little features and no
> > integration with Github. I think using it achieves nothing but additional
> > overhead.
> >
> > Thanks,
> > Eric
> >
>

Re: Vote to stop using JIRA

[Mu Li]

Hi Naveen,

Can we clarify that how JIRA improved the project?  One key Apache spirit is
about transparent, but I didn't see the current way we are using JIRA
improves it. Comparing to Spark, one major problem is that we have 10x less
active contributors. Even PyTorch is 3x more active (#commits, #LOC
#contributors) than us. If JIRA makes contributing harder, we should
consider a better approach.

Best
Mu

On Fri, Jun 8, 2018 at 10:35 AM, Naveen Swamy  wrote:

> -1 (binding)
>
> The very reason why JIRA was suggested so that the project is more open on
> the features that are worked on. There are 900+ issues, that once in a
> while gets closed without any reason has happened already once.
> There is already integration with GitHub PRs, please check it out.
>
> Features pop into the code-base without any discussion, they also get
> removed without any discussion. PRs come in when the feature is complete,
> not giving others  opportunity to understand/contribute or have a say.
>
> If this project embraces the true Apache spirit and follow successful
> practices we could get lot more people excited about this project. Many
> successful Apache projects use JIRA, look at Apache Spark which has 1250+
> contributors and built a community of 500,000 people around the world.
>
> -Naveen
>
>
> On Fri, Jun 8, 2018 at 10:27 AM, Eric Xie  wrote:
>
> > Hi,
> >
> > Since all of MXNet's development happens on Github, I think it's
> > sufficient to use Github Issues and Github Projects for tracking. There
> are
> > also many other plugins you can add to Github if issues and projects are
> > not enough.
> >
> > It's very easy to cross reference PRs and issues for tracking. In
> > comparison, JIRA is an outdated system with very little features and no
> > integration with Github. I think using it achieves nothing but additional
> > overhead.
> >
> > Thanks,
> > Eric
> >
>

Re: Vote to stop using JIRA

[Naveen Swamy]

-1 (binding)

The very reason why JIRA was suggested so that the project is more open on
the features that are worked on. There are 900+ issues, that once in a
while gets closed without any reason has happened already once.
There is already integration with GitHub PRs, please check it out.

Features pop into the code-base without any discussion, they also get
removed without any discussion. PRs come in when the feature is complete,
not giving others  opportunity to understand/contribute or have a say.

If this project embraces the true Apache spirit and follow successful
practices we could get lot more people excited about this project. Many
successful Apache projects use JIRA, look at Apache Spark which has 1250+
contributors and built a community of 500,000 people around the world.

-Naveen


On Fri, Jun 8, 2018 at 10:27 AM, Eric Xie  wrote:

> Hi,
>
> Since all of MXNet's development happens on Github, I think it's
> sufficient to use Github Issues and Github Projects for tracking. There are
> also many other plugins you can add to Github if issues and projects are
> not enough.
>
> It's very easy to cross reference PRs and issues for tracking. In
> comparison, JIRA is an outdated system with very little features and no
> integration with Github. I think using it achieves nothing but additional
> overhead.
>
> Thanks,
> Eric
>