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:
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 <
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
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,
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
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:
> 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
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
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
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,
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
>
-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
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
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
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
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
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
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
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
+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
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
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
+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
+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
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
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
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
+ 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
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
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
+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
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
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,
-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.
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.
35 matches
Mail list logo
