RE: [VOTE] Release MXNet version 1.2.1.RC1

[Yasser Zamani]

Hi Sina,

Do you encounter that issue during building MXNet from source (including tests) 
or on your own code/test? Three days ago I was successful to build master via 
VS2017 with Intel MKL+MKLDNN support. If you have an own test/code which fails, 
please pull request it into master.

Regards.

>-Original Message-
>From: Jim Jagielski 
>Sent: Tuesday, July 17, 2018 5:06 PM
>To: dev@mxnet.incubator.apache.org
>Subject: Re: [VOTE] Release MXNet version 1.2.1.RC1
>
>FWIW, neither can I.
>
>> On Jul 16, 2018, at 8:45 PM, Anirudh  wrote:
>>
>> Hi Sina,
>>
>> I am unable to reproduce this issue on 1.2.1.
>>
>> Anirudh
>>
>> On Mon, Jul 16, 2018 at 5:26 PM, Afrooze, Sina  wrote:
>>
>>> I know voting is over for this release, but I think this issue may
>>> warrant
>>> delaying: https://github.com/apache/incubator-mxnet/issues/11772.
>>> Looks like save_parameters doesn't fix the issue it is designed to
>>> fix (i.e. two instances of the same network in the same session) if LSTMs 
>>> are
>used.
>>>
>>> - Sina
>>>
>>> On 7/12/18, 3:27 PM, "Hao Jin"  wrote:
>>>
>>>+1 Built on Ubuntu with CUDA 9.0 and CuDNN 7 and verified that
>>> sparse tests
>>>are passing.
>>>Hao
>>>
>>>On Thu, Jul 12, 2018 at 3:01 PM, Sergio Fernández
>>> 
>>> wrote:
>>>
 +1 (binding)

 On Mon, Jul 9, 2018, 16:53 Roshani Nagmote <
>>> roshaninagmo...@gmail.com>
 wrote:

> Hi all,
>
> I would like to propose a vote to release Apache MXNet (incubating)
 version
> 1.2.1.RC1. Voting will start now (Monday, Jul 9th) and end at 5:50
>>> PM
> PDT, Thursday, July 12th.
>
> Link to release candidate 1.2.1.rc1:
> *https://github.com/apache/incubator-mxnet/releases/tag/1.2.1.rc1
> 
> View this page, click on "Build from Source", and use the source
>>> code
> obtained from 1.2.1.rc1 tag:
> https://mxnet.incubator.apache.org/install/index.html
>
> (Note: The README.md points to the 1.2.1 tag and does not work at
>>> the
> moment.)
>
> Please remember to test first before voting accordingly:
>
> +1 = approve
> +0 = no opinion
> -1 = disapprove (provide reason)
>
> Thanks,
> Roshani
>

>>>
>>>
>>>
>>>

FW: Success at Apache: The Apache Way for Executives

[Yasser Zamani]

I thought these could be great for our community so I shared them here. 

"The most important and first lesson I learned from the Apache Community was to 
avoid short term gains that were unsustainable in the long term. This very 
important core principle derives in part from the concept of "community over 
code". It does not matter how much code you write, or how good your code is if 
you cannot get along, compromise, and communicate respectfully with your peers. 
The code does not write itself, its the community behind it that keeps the code 
alive." Alex Karasulu, an entrepreneur with over 25 years of experience said.

Best Regards.

>-Original Message-
>From: Sally Khudairi 
>Sent: Monday, July 9, 2018 8:00 PM
>To: Apache Announce List 
>Subject: Success at Apache: The Apache Way for Executives
>
>[this post is available online at https://s.apache.org/2Wg8 ]
>
>by Alex Karasulu
>
>I'm a long time member of the Apache Software Foundation and have been an
>executive officer of several corporations over the course of the past 20 years.
>I've co-founded several projects in the community and mentored several others.
>
>The "Apache Way" has benefited several aspects of my life, however I never
>imagined it would help make me a better executive. Even non-technical
>executives, in organizations totally outside of the realm of technology, can
>benefit from the Zen of the Apache Way.
>
>Life is hard when you're stupid
>
>I was involved in a number of early dot com startups as an executive, however
>that was before my involvement with Apache and long before any exposure to
>the Apache Way. To this day, I remember how opportunistic decisions for short
>term gains, the lack of collaboration, openness and communication kept causing
>friction that made my job and ultimately my life much harder than it had to be.
>
>Learning while on the job
>
>Exposure to the philosophy began early even while lurking on mailing lists but
>picked up more while incubating the Apache Directory Project where I worked
>with others to grow an active community. Meanwhile, I was the Chief
>Technology Officer of a large financial services company called Alliance 
>Capital
>Partners. It was 2002, and the first time I had to conduct myself as a C-Suite
>executive in an enterprise that was obviously not a technology company.
>Incidentally, the lack of hands-on coding got me working on a pet project that
>ultimately became the Apache Directory Server and Apache MINA. The project
>was medicine to keep me sane and technically up to date. Unbeknownst to me,
>this would save my career, not as a developer, but as an executive.
>
>The Apache Way makes life easier
>
>The most important and first lesson I learned from the Apache Community was to
>avoid short term gains that were unsustainable in the long term. This very
>important core principle derives in part from the concept of "community over
>code". It does not matter how much code you write, or how good your code is if
>you cannot get along, compromise, and communicate respectfully with your
>peers. The code does not write itself, its the community behind it that keeps 
>the
>code alive. Involving only the most technically proficient contributors should
>never trump the need to build a sustainable community. I saw projects often
>suffer from self-centered yet skilled coders added as committers for short term
>gain at the detriment of a healthy sustainable community. So as a corollary to
>community over code, avoid short term gains that get in the way of the long 
>term
>sustainability of an organization's culture. This has immense applications for 
>any
>executive in both technical and non-technical fields.
>
>While growing my new development organization in this financial services
>organization, I decided to avoid hiring people that seemed to be very skilled
>technically but lacked the desire or social skills to collaborate with others. 
>Thanks
>to experiences at Apache, I could start telling them apart much better than I 
>did
>before. Also, I was calmer and less anxious when hiring to fill gaps on the 
>team. It
>was better not to have the resource than to introduce a bad apple onto the 
>team.
>
>This was contrary to how I had operated earlier and started producing great
>results. The application of this basic principle lead to a solid team that 
>worked
>better together than ever before in the past. They were able to leverage each
>others' skills thanks to collaboration to out perform any one skilled 
>developer.
>This is all thanks to the concept of community over code where social skills, 
>and
>collaboration were stressed more than technical skills. In the end, being kind,
>listening, and asking smart questions begets the kind of collaboration needed 
>to
>build complex software.
>
>Not only did this help with developers, it also worked with teams that did not
>produce code like project managers under the CTO office. The rule is golden, 
>and
>IMHO should be applied to any executiv

Re: Beam's recent community development work

[Yasser Zamani]

Thank you very much Kenneth, they're nice points!

Regards.

On 6/30/2018 10:45 AM, Kenneth Knowles wrote:
> Hi all,
> 
> The ASF board suggested that we (Beam) share some of what we've been doing
> for community development with d...@community.apache.org and
> memb...@apache.org. So here is a long description. I have included
> d...@beam.apache.org because it is the subject, really, and this is & should
> be all public knowledge.
> 
> We would love feedback! We based a lot of this on reading the community
> project site, and probably could have learned even more with more study.
> 
> # Background
> 
> We face two problems in our contributor/committer-base:
> 
> 1. Not enough committers to review all the code being contributed, in part
> due to recent departure of a few committers
> 2. We want our contributor-base (hence committer-base) to be more spread
> across companies and backgrounds, for the usual Apache reasons. Our user
> base is not active and varied enough to make this automatic. One solution
> is to make the right software to get a varied user base, but that is a
> different thread :-) so instead we have to work hard to build our community
> around the software we have.
> 
> # What we did
> 
> ## Committer guidelines
> 
> We published committer guidelines [1] for transparency and as an
> invitation. We start by emphasizing that there are many kinds of
> contributions, not just code (we have committers from community
> development, tech writing, training, etc). Then we have three aspects:
> 
> 1. ASF code of conduct
> 2. ASF committer responsibilities
> 3. Beam-specific committer responsibilities
> 
> The best way to understand is to follow the link at the bottom of this
> email. The important part is that you shouldn't be proposing a committer
> for other reasons, and you shouldn't be blocking a committer for other
> reasons.
> 
> ## Instead of just "[DISCUSS] Potential committer XYZ" we discuss every
> layer
> 
> Gris (CC'd) outlined this: people go through these phases of relationship
> with our project:
> 
> 1. aware of it
> 2. interested in it / checking it out
> 3. using it for real
> 4. first-time contributor
> 5. repeat contributor
> 6. committer
> 7. PMC
> 
> As soon as we notice someone, like a user asking really deep questions, we
> invite discussion on private@ on how we can move them to the next level of
> engagement.
> 
> ## Monthly cadence
> 
> Every ~month, we call for new discussions and revisit ~all prior
> discussions. This way we do not forget to keep up this effort.
> 
> ## Individual discussions
> 
> For each person we have a separate thread on private@. This ensures we have
> quality focused discussions that lead to feedback. In collective
> discussions that we used to do, we often didn't really come up with
> actionable feedback and ended up not even contacting potential committers
> to encourage them. And consensus was much less clear.
> 
> ## Feedback!
> 
> If someone is brought up for a discussion, that means they got enough
> attention that we hope to engage them more. But unsolicited feedback is
> never a good idea. For a potential committer, we did this:
> 
> 1. Send an email saying something like "you were discussed as a potential
> committer - do you want to become one? do you want feedback?"
> 2. If they say yes (so far everyone) we send a few bullet points from the
> discussion and *most important* tie each bullet to the committer
> guidelines. If we have no feedback about which guidelines were a concern,
> that is a red flag that we are being driven by bias.
> 
> We saw a *very* significant increase in engagement from those we sent
> feedback to, and the trend is that they almost all will become committers
> over time.
> 
> ## Results
> 
>  - Q1 we had no process and we added no new committers or PMC members.
>  - Q2 when we tried these new things we added 7 committers and 1 PMC
> member, with ~3~4 obvious committer candidates for next time around, plus
> positive feedback from other contributors, spread across five companies.
> 
> We've had a pretty major uptick in building Beam as a result.
> 
> ## Review-then-commit
> 
> We are dedicated to RTC as the best way to build software. Reviews not only
> make the code better, but (with apologies to ASF/GNU differences) as RMS
> says "The fundamental act of friendship among programmers is the sharing of
> programs" and reviews are where we do that.
> 
> As a minor point, we also changed our "review-then-commit" policy to
> require that *either* the reviewer or the author be a committer. Previously
> the reviewer had to be a committer. Rationale: if we trust someone as a
> committer, we should trust their choice of reviewer. This also helps the
> community, as it engages non-committers as reviewers.
> 
> 
> 
> If you made it through this long email, thanks for reading!
> 
> Kenn
> 
> [1] https://beam.apache.org/contribute/become-a-committer/
> 

Re: Vote to stop using JIRA

[Yasser Zamani]

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 
mailto: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: [LAZY VOTE] Test coverage of PRs

[Yasser Zamani]

+1 but just as an MXNet lover newbie :)

We at Apache Struts, already use "coveralls" and I personally like it a
lot even with some limitations with it. It doesn't allow us to merge a
PR with a not tested code. It reports us where are those not covered new
codes.

Regards.

On 6/21/2018 7:13 PM, Marco de Abreu wrote:
> To avoid any confusion, I have disable the PR comments at
> https://github.com/apache/incubator-mxnet/pull/11344/files#diff-1f7b4b85ed8525c5239f741431a72872R25.
> Thus, the data will only be recorded in the background is then retrievable
> at https://codecov.io/gh/apache/incubator-mxnet/pulls.
> 
> -Marco
> 
> On Thu, Jun 21, 2018 at 6:43 AM Marco de Abreu 
> wrote:
> 
>> Hi Kellen,
>>
>> Thanks for your feedback.
>>
>> The same argument about a hosted service could be applied to GitHub - we
>> could just use the git repository hosted under Apache Infra then and
>> completely stick to JIRA. This service gives us the advantage of being free
>> of charge, a mature project and having built-in support for all languages
>> we run in this project. If you got an open source software which offers the
>> same features and is as easy to manage, I'm happy to take suggestions.
>>
>> As stated previously, we're going to start with Python and C++ coverage,
>> evaluate it over the following days/weeks and then discuss how we should
>> move forward. I'm happy to take contributions from the community to extend
>> the coverage across more languages. For now, I'd just like to gather some
>> data.
>>
>> Best regards,
>> Marco
>>
>>
>> kellen sunderland  schrieb am Do., 21. Juni
>> 2018, 11:15:
>>
>>> -0.1 (non-binding).
>>>
>>> Looks good, and I like the idea of adding coverage, however I have a few
>>> minor issues with this approach:
>>>
>>> First it seems to use a hosted service, which can disappear / be acquired
>>> /
>>> change terms at any time.  In general I would try and avoid using services
>>> like this for Apache projects.  I don't feel as strongly about this as
>>> some
>>> in the community do, but there are so many open source alternatives to
>>> generate coverage reports that I'm not sure why we have to go the Saas
>>> route in this case.
>>>
>>> Secondly the core library is written in C++.  Most of the significant bugs
>>> I've seen in MXNet so far have been in the C++ code.  I'd suggest we focus
>>> on coverage reports for C++ before, or at least in addition to Python.  I
>>> feel less strongly about the other languages, but coverage in other areas
>>> (i.e. Scala) might also be nice eventually.
>>>
>>> -Kellen
>>>
>>> On Thu, Jun 21, 2018 at 4:59 AM Chris Olivier 
>>> wrote:
>>>
 we should have a betting pool on what the current coverage is.

 On Wed, Jun 20, 2018 at 7:54 PM Naveen Swamy 
>>> wrote:

> +1 to collect data on coverage.
>
> On Wed, Jun 20, 2018 at 7:38 PM, Marco de Abreu <
> marco.g.ab...@googlemail.com.invalid> wrote:
>
>> Hello,
>>
>> for now, this is only a test for myself and a way to gather data in
 order
>> to give us the possibility to make a data-driven decision. So far,
>>> we
> have
>> not decided on the implications and which restrictions we will set
>>> as
>> result for the produced metrics and I'd like to postpone that until
>>> we
> know
>> the confidence of the system. This impact is one of the aspects I'd
 like
> to
>> assess in the next weeks.
>>
>> The initial goal is to give the reviewer an additional tool to
>>> assess
 the
>> coverage of one's PR. One example could be the optimization of some
> backend
>> logic. The reviewer would then see if the changed codeis actually
>>> being
> hit
>> by any tests or if they are being missed entirely. I agree that just
 the
>> percentage could be highly misleading and we should review that very
>> clearly.
>>
>> For now, I'd only like to gather the data in the background. I would
> follow
>> up with a big thread on dev@ about my observations, my
>>> recommendations
> and
>> the possible options we have to use the data. We can then decide as
>> community how exactly we would like to proceed and how much
>>> importance
 we
>> give to the generated reports.
>>
>> Best regards,
>> Marco
>>
>>
>>
>> On Wed, Jun 20, 2018 at 7:23 PM Tianqi Chen <
>>> tqc...@cs.washington.edu>
>> wrote:
>>
>>> While I think test coverage is a nice information to have. I would
> object
>>> to using this as a metric to decide whether a PR should be merged.
>>> Code-cov act as a mere coverage of APIs, which is a useful
>>> aspect, it
> can
>>> be misleading in many cases, especially when such change involves
>>> cross-language APIs and automatically generated wrapper.
>>> Sometimes the code-cov shows a negative impact on coverage while
>>> CI
>> passes,
>>> and the giving information was quite misleading if you

Re: users@mxnet

[Yasser Zamani]

On 6/18/2018 9:18 PM, Jim Jagielski wrote:
> IMO, that is the wrong way to look at it.
> 
> A users@ mailing list is a great, easy, low-cost and low-overhead way of 
> *increasing* the user community and providing an extra level of support. 
> Unless there is "strong evidence" that this is NOT the case, I would 
> recommend we create the list.


As an already Apache Committer of Struts, I also prefer mail list like Jim.

I fell in love with MXNet and I'm still learning hard to being able to
have contributions one day. It was somehow hard for me to also register
and daily monitor another system (your user forum). My feel was same as
your current feel about a new mail list, but, I remembered one rule in
Apache Way: "At Apache, deciders are who do the work". And as I didn't
have any contribution till that time, then I thought I must respect your
decision, so I registered there!

However, I personally still recommend sticking together with Apache
INFRA under Apache Way umbrella as much as possible. I think these help
us to standardize things, understanding each other better and finally
get a graduation from Apache Incubator. Anyway, finally, you who have
done or do the work, are deciders :)

Best Regards.

Re: "What does the Apache board do"

[Yasser Zamani]

On 6/12/2018 4:24 PM, Sebastian wrote:
> Hi,
> 
> I just came across a video where two of the directors of the ASF talk
> about what the board looks for in healthy apache projects. (Note that
> they look at top level projects only and things are a little different
> in the incubator). However, I still think this video contains many
> useful views, especially for the MXNet community:
> 
> https://www.youtube.com/watch?v=jm_whow_zxk

I would like to add two more resources defined for Incubating projects:
[1] and [2]. They are describing how we can have a successful graduation
to top level project for MXNet :)

Regards.

[1]
https://incubator.apache.org/guides/graduation.html#creating_an_open_and_diverse_community
[2] https://incubator.apache.org/guides/community.html

Re: Vote to stop using JIRA

[Yasser Zamani]

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: About Becoming a Committer

[Yasser Zamani]

On 6/9/2018 12:45 AM, Sheng Zha wrote:
> There have been a couple of offline inquiries from contributors about
> becoming a committer. From those inquiries, it seems that there’s confusion
> in our community about how to become a committer, so I’d like to take this
> opportunity to clarify.
> 
> The guideline about becoming a committer can be found at
> https://cwiki.apache.org/confluence/display/MXNET/Becoming+a+Committer.

I think that page at above link is great but the problem is new visitors
cannot find it quickly then they ask privately from you. I myself was
looking for it at mxnet.incubator.apache.org, so clicked on
"Community->Contribute", the I read all page then I saw a link to wiki
on page i.e. "MXNet Confluence Wiki: Development" where I guessed I
might find something in wiki so clicked that. Then I saw "Becoming a
Committer" in left side wiki's menu.

I think we'll get fewer private inquiries on this if we add a direct
link about it at
https://mxnet.incubator.apache.org/community/contribute.html

Regards.

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

[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

[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

[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

[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."