[prev in list] [next in list] [prev in thread] [next in thread] 

List:       incubator-general
Subject:    Re: Giving our PMs and contributors triage rights on GitHub
From:       Sheng Zha <zhasheng () apache ! org>
Date:       2020-08-24 20:02:17
Message-ID: pony-fd9da504b63c1736e52a84ae954da2a315f2f28a-0f234b71c43197ec1ee92e9980ba7c745adf3512 () general ! incubator ! apache ! org
[Download RAW message or body]

+1. Apache is an inclusive community and the individual projects decide what contribution counts as merit in the community. In the case of triaging and project management, it's a very time consuming task and IMO more projects than just us MXNet would welcome helping hands in that area. Now that Github provides the tools, it would be great to enable the projects to have the option of receiving project management as contribution. For this purpose, I don't think we necessarily need to tie it to the committer rights just due to lack of other status in governance hierarchy. In TVM, the practice of recognizing people as reviewers of the project has seen great success and has helped the project grow healthily. This is a practice we are thinking to adopt in MXNet too. Being able to provide project management access to such recognized good citizens will certainly be welcome in MXNet.

Best,
Sheng

On 2020/08/21 15:09:03, Maxime Beauchemin <maximebeauchemin@gmail.com> wrote: 
> I can think of 3 main reasons backing the approach that I'm suggesting:
> 
> - as someone who's kicked off votes for dozens of committers across 3
> communities, I know how slow and cumbersome the process of voting
> committers in is. Effectively, it always takes more than 2 weeks (when
> things go well) and involves many async touchpoints with many people.
> - the chicken and egg issue discussed in this thread: for this type of role
> triage is the probably the absolute best onramp
> - personally I don't like the idea of diluting committerhood, it should be
> earned through merit, not given so that people have a path to onramp
> 
> About diversity, we have to be creative and challenge the status quo
> to make significant progress on this. Clearly offering a new onramp for
> roles that historically haven't been well recognized in ASF projects is a
> great way to improve diversity of roles, and consequently of thoughts and
> backgrounds.
> 
> Max
> 
> On Thu, Aug 20, 2020 at 3:08 AM Justin Mclean <justin@classsoftware.com>
> wrote:
> 
> > Hi,
> >
> > > Last thought: I don't have data on this, but I think the ASF could be
> > doing
> > > better at diversity (see the ApacheCon picture <
> > https://www.apachecon.com/>
> > > as anecdotal evidence). Being inclusive of a wider range of roles and
> > > offering diverse paths to "committerhood" could really help with this.
> > For
> > > Superset and many other projects, finding ways to involve and empower PMs
> > > and designers to partake in the open source process is vital.
> >
> > We could always be doing a better job at diversity, but I'm not sure
> > that's the issue here.
> >
> > The bar to committership should be low and all forms of contribution
> > considered by the (P)PMC. Many people end up being voted into communities
> > without making code contributions, and this has happened to me on more than
> > one occasion.
> >
> > Someone who is being paid to work on a project should have no issues is
> > achieving this in a very short time. So I'm not sure what the issue is
> > here. Is it in engaging people who have been assigned these roles to be
> > publicly involved with the project and follow Apache values or is it
> > something else?
> >
> > Thanks,
> > Justin
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

[prev in list] [next in list] [prev in thread] [next in thread]