Re: Giving our PMs and contributors triage rights on GitHub

[Sheng Zha]

+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  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 
> 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-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
> 

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

Re: Giving our PMs and contributors triage rights on GitHub

[Maxime Beauchemin]

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 
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-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Giving our PMs and contributors triage rights on GitHub

[Justin Mclean]

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 
> 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-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Giving our PMs and contributors triage rights on GitHub

[Justin Mclean]

Hi,

If you trust someone access that allows issue and pull request admin, why would 
you not trust them with commit access to the codebase?

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

Re: Giving our PMs and contributors triage rights on GitHub

[Tomasz Urbaszek]

There's a similar discussion about triage role on ComDev mailing list:
https://lists.apache.org/thread.html/r617c960eae5a33e8f911c8606f93b6826f2724b3260553a162e2f9f4%40%3Cdev.community.apache.org%3E

Cheers,
Tomek

On 2020/08/13 16:27:29, Maxime Beauchemin  wrote: 
> xposting from d...@superset.apache.org - what's the right place to post this
> for ASF-infra's attention?
> 
> ---
> 
> Hi all,
> 
> It just came to my attention that GitHub added a new "triage" access level
> at the repo level.
> https://github.blog/changelog/2019-05-23-triage-and-maintain-roles-beta/
> 
> In the past, we've identified that it was impossible for non-committers
> (especially our PMs and contributors-that-are-not-yet-committers) to help
> us triage issues, apply labels, assign reviews, close and reopen issues as
> needed. It's really clear to me that we really need all the help we can get
> in this area, and that not being able to involve more people into this
> process hurts us, and is a clear operational downside of using the ASF
> infra.
> 
> More technically, I think the way to make that easy and painless would be
> to add a new entry to the `.asf.yaml` file that would enable maintainers to
> assign the "triage" role to whoever they see fit. For reference, here's
> more context on that piece of automation I'd like to latch this onto here:
> https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features
> 
> Max
> 

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

Re: Giving our PMs and contributors triage rights on GitHub

[Matt Sicker]

For what it's worth, new contributors to Ubuntu typically start by doing
bug triaging, though that’s using Launchpad which is sort of designed
around that idea.

On Mon, Aug 17, 2020 at 19:50 Maxime Beauchemin 
wrote:

> Thank you for the comments Julian and Jarek.
>
>
>
> A few related thoughts:
>
>
>
> - the "triage" GitHub role is very limited (labeling, open/closing, assign,
>
> kanban)
>
> <
> https://docs.github.com/en/github/setting-up-and-managing-organizations-and-teams/repository-permission-levels-for-an-organization#repository-access-for-each-permission-level
> >and
>
> I don't think it can be abused. Ideally it should be easy for us to give
>
> this role to contributors that are not-yet-committers that want to help
>
> with labeling, flagging duplicates, ... Can someone think of any way that
>
> this can be abused? Rogue-labeling? Bulk-closing/opening issues?
>
> - PMs (project, product and program managers) have aligned interests with
>
> contributors towards the success of the project, I don't think of them as
>
> "business people". In our community, they've been the connective tissue
>
> between individuals and across organizations, facilitating collaboration
>
> across boundaries and at scale. They do so much that's invisible to the
>
> ASF's traditional way of thinking, like interviewing users, doing
>
> competitive research, running surveys, analyzing issues, bridging with
>
> designers, ...
>
> - the chicken & egg problem is a thing where it absolutely makes sense for
>
> PMs to build context while triaging. Currently they can comment but they
>
> cannot label, reopen, pin issues, manage milestones, which means it's hard
>
> to add value while ramping up
>
> - voting them in as committers is time consuming, error-prone and slow
>
>
>
> I think it's pretty clear that to build a great project and community, it
>
> takes much more than just software engineers, especially for projects
>
> "up-the-stack"! It takes all sorts of people with diverse skills and roles
>
> to make a project like Superset successful. Diversity is key, and being
>
> welcoming and inclusive to different types of contribution is super
>
> important.
>
>
>
> Last thought: I don't have data on this, but I think the ASF could be doing
>
> better at diversity (see the ApacheCon picture  >
>
> 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.
>
>
>
> Max
>
>
>
> On Fri, Aug 14, 2020 at 5:17 AM Jarek Potiuk  wrote:
>
>
>
> > Few comments, needs of the Apache Airflow project.
>
> >
>
> > In short: big +1 on enabling the "triage role".
>
> >
>
> > On 2020/08/13 18:43:06, Julian Hyde  wrote:
>
> > > By PM, I presume that you mean either Product Manager or Program
>
> > Manager. I’ve worked at a few companies that practiced “commercial open
>
> > source”, and there is inherent tension in the relationship with the
>
> > “business” people.
>
> >
>
> > I read that as Project Manager as well. I think when there are many
> issues
>
> > in a project, it is often useful that the teams working on a project also
>
> > have a Project Manager that helps the team to remove obstacles (this is,
> I
>
> > think the main role of great Project Manager). This is the case, where
>
> > several companies have whole teams dedicated to improve the OSS project.
>
> > The developers still act as sole contributors on the OSS project, but
> they
>
> > are paid by another organisation to do so and the Project Manager is
> there
>
> > to make sure the teams work well together as well as individuals. We have
>
> > some great example of that in our company where we have teams of
>
> > contributors (also committers and PMCs) working on Apache Airflow and
>
> > Apache Beam projects (among others) and there are PMs for those projects.
>
> > What's more - those PMs are not there to provide "Business direction" but
>
> > to make people working "well" together and there are some good example of
>
> > people like that who learned how to do it in the
>
> >  open-source cases. Quite recently at the Airflow Summit, our PM Karolina
>
> > - gave (together with our CTO) great talk about it and explained the
>
> > challenges and benefits of having a PM in such team:
>
> >
> https://www.youtube.com/watch?v=KIEMEYM2PEs=PLGudixcDaxY3RGLSlWoN_cEEXhIT1OPmj=37
>
> > . I can heartily recommend the talk to everyone who is interested in the
>
> > subject!
>
> >
>
> > What's more - if you have great PMs who are really part of the team, they
>
> > are super happy to contribute to the whole OSS project - and being able
> to
>
> > help with the teamwork (for example by organixing issues and helping with
>
> > tracking the progress) might be a huge help for both - the teams and the
>
> > project. I think we are really 

Re: Giving our PMs and contributors triage rights on GitHub

[Maxime Beauchemin]

Thank you for the comments Julian and Jarek.

A few related thoughts:

- the "triage" GitHub role is very limited (labeling, open/closing, assign,
kanban)
and
I don't think it can be abused. Ideally it should be easy for us to give
this role to contributors that are not-yet-committers that want to help
with labeling, flagging duplicates, ... Can someone think of any way that
this can be abused? Rogue-labeling? Bulk-closing/opening issues?
- PMs (project, product and program managers) have aligned interests with
contributors towards the success of the project, I don't think of them as
"business people". In our community, they've been the connective tissue
between individuals and across organizations, facilitating collaboration
across boundaries and at scale. They do so much that's invisible to the
ASF's traditional way of thinking, like interviewing users, doing
competitive research, running surveys, analyzing issues, bridging with
designers, ...
- the chicken & egg problem is a thing where it absolutely makes sense for
PMs to build context while triaging. Currently they can comment but they
cannot label, reopen, pin issues, manage milestones, which means it's hard
to add value while ramping up
- voting them in as committers is time consuming, error-prone and slow

I think it's pretty clear that to build a great project and community, it
takes much more than just software engineers, especially for projects
"up-the-stack"! It takes all sorts of people with diverse skills and roles
to make a project like Superset successful. Diversity is key, and being
welcoming and inclusive to different types of contribution is super
important.

Last thought: I don't have data on this, but I think the ASF could be doing
better at diversity (see the ApacheCon picture 
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.

Max

On Fri, Aug 14, 2020 at 5:17 AM Jarek Potiuk  wrote:

> Few comments, needs of the Apache Airflow project.
>
> In short: big +1 on enabling the "triage role".
>
> On 2020/08/13 18:43:06, Julian Hyde  wrote:
> > By PM, I presume that you mean either Product Manager or Program
> Manager. I’ve worked at a few companies that practiced “commercial open
> source”, and there is inherent tension in the relationship with the
> “business” people.
>
> I read that as Project Manager as well. I think when there are many issues
> in a project, it is often useful that the teams working on a project also
> have a Project Manager that helps the team to remove obstacles (this is, I
> think the main role of great Project Manager). This is the case, where
> several companies have whole teams dedicated to improve the OSS project.
> The developers still act as sole contributors on the OSS project, but they
> are paid by another organisation to do so and the Project Manager is there
> to make sure the teams work well together as well as individuals. We have
> some great example of that in our company where we have teams of
> contributors (also committers and PMCs) working on Apache Airflow and
> Apache Beam projects (among others) and there are PMs for those projects.
> What's more - those PMs are not there to provide "Business direction" but
> to make people working "well" together and there are some good example of
> people like that who learned how to do it in the
>  open-source cases. Quite recently at the Airflow Summit, our PM Karolina
> - gave (together with our CTO) great talk about it and explained the
> challenges and benefits of having a PM in such team:
> https://www.youtube.com/watch?v=KIEMEYM2PEs=PLGudixcDaxY3RGLSlWoN_cEEXhIT1OPmj=37
> . I can heartily recommend the talk to everyone who is interested in the
> subject!
>
> What's more - if you have great PMs who are really part of the team, they
> are super happy to contribute to the whole OSS project - and being able to
> help with the teamwork (for example by organixing issues and helping with
> tracking the progress) might be a huge help for both - the teams and the
> project. I think we are really blessed by having such people in our
> company, but I think there are more people like that.
>
> > The key questions are whether a PM can participate in the community
> (which means being active on the dev list), make contributions of value to
> the project (‘earn merit’), and can put aside their professional
> affiliation and act solely in the interests of the project. This is
> precisely what we require committers to do.
>
> Yes. It's possible and I think it's the same for different people.
> Actually this statement makes me quite a bit 

Re: Giving our PMs and contributors triage rights on GitHub

[Jarek Potiuk]

Few comments, needs of the Apache Airflow project.

In short: big +1 on enabling the "triage role".

On 2020/08/13 18:43:06, Julian Hyde  wrote: 
> By PM, I presume that you mean either Product Manager or Program Manager. 
> I’ve worked at a few companies that practiced “commercial open source”, and 
> there is inherent tension in the relationship with the “business” people.

I read that as Project Manager as well. I think when there are many issues in a 
project, it is often useful that the teams working on a project also have a 
Project Manager that helps the team to remove obstacles (this is, I think the 
main role of great Project Manager). This is the case, where several companies 
have whole teams dedicated to improve the OSS project. The developers still act 
as sole contributors on the OSS project, but they are paid by another 
organisation to do so and the Project Manager is there to make sure the teams 
work well together as well as individuals. We have some great example of that 
in our company where we have teams of contributors (also committers and PMCs) 
working on Apache Airflow and Apache Beam projects (among others) and there are 
PMs for those projects. What's more - those PMs are not there to provide 
"Business direction" but to make people working "well" together and there are 
some good example of people like that who learned how to do it in the 
 open-source cases. Quite recently at the Airflow Summit, our PM Karolina - 
gave (together with our CTO) great talk about it and explained the challenges 
and benefits of having a PM in such team: 
https://www.youtube.com/watch?v=KIEMEYM2PEs=PLGudixcDaxY3RGLSlWoN_cEEXhIT1OPmj=37
 . I can heartily recommend the talk to everyone who is interested in the 
subject! 

What's more - if you have great PMs who are really part of the team, they are 
super happy to contribute to the whole OSS project - and being able to help 
with the teamwork (for example by organixing issues and helping with tracking 
the progress) might be a huge help for both - the teams and the project. I 
think we are really blessed by having such people in our company, but I think 
there are more people like that.
 
> The key questions are whether a PM can participate in the community (which 
> means being active on the dev list), make contributions of value to the 
> project (‘earn merit’), and can put aside their professional affiliation and 
> act solely in the interests of the project. This is precisely what we require 
> committers to do.

Yes. It's possible and I think it's the same for different people. Actually 
this statement makes me quite a bit uncomfortable. It somehow implies 
developer's "superiority" in terms of being able to comply with the rules of 
Apache regarding professional affiliation. It hurts my way of thinking about 
people being individuals and I personally think that there is a 
"discriminating" thought hidden in this statement.

Being developer myself I could also feel that way, but I think personal 
integrity is not really related to the role you have in any company or your job 
description or affiliation with the company. I know both "business" people and 
"developers" with both excellent integrity and very poor one. So I totally 
don't see why "business people" would be inferior in this role. Both business 
people and developers have different kinds of commercial relation, sometimes 
ownership sometimes pay structure that might make it easier or more difficult 
to separate the affiliation from the organisation they are in - but I think 
it's eventually all the matter of personal integrity, peer pressure and a 
number of other factors that determine the actions of that individual - 
regardless of the job role they have. I - for one - have a significant 
ownership in the company i work in (being co-founder) but my role is purely 
engineering one - but my ownership could also influence decisions I make.

> So, by this logic, a PM would earn committership in a few short months. But I 
> guess you’re running into a chicken-and-egg problem: if the only 
> contributions a PM can make are triaging bugs, then how can they earn enough 
> merit to be made a contributor? One solution is for them to contribute in 
> other ways, for example writing documentation and testing.

That's the very thing - chicken and egg - I think it is very hot and important 
topic discussed recently that we should have more "non-code" committers in 
Apache projects and how valuable they are. I think we should make it easy for 
them to contribute. In our case - more often than not - PMs input to the 
documentation can be very, very limited. Most of the documentation we have 
should really be written down by the developers. For testing - we do everything 
possible to automate it in our project, and again - there is a limited help PMs 
can provide here. But this is entirely different story for organizing work (in 
whatever way). It's entirely different for Open Source projects than 

Re: Giving our PMs and contributors triage rights on GitHub

[Julian Hyde]

By PM, I presume that you mean either Product Manager or Program Manager. I’ve 
worked at a few companies that practiced “commercial open source”, and there is 
inherent tension in the relationship with the “business” people.

The key questions are whether a PM can participate in the community (which 
means being active on the dev list), make contributions of value to the project 
(‘earn merit’), and can put aside their professional affiliation and act solely 
in the interests of the project. This is precisely what we require committers 
to do.

So, by this logic, a PM would earn committership in a few short months. But I 
guess you’re running into a chicken-and-egg problem: if the only contributions 
a PM can make are triaging bugs, then how can they earn enough merit to be made 
a contributor? One solution is for them to contribute in other ways, for 
example writing documentation and testing.

There is also a concern whether they can "act solely in the interests of the 
project”. Most of the PMs I know can do this, but a few cannot. Maybe it’s part 
of the ethics of “fiduciary responsibility” taught at business school; many PMs 
see themselves as potential officers of their company someday, and act 
accordingly.

Also beware establishing this model in a project where a majority of committers 
are employed by one company. The business people at such a company, even if 
they are entirely invisible on the dev list, have huge influence over the 
project by what development efforts they choose to fund, and how much time they 
give committers to review patches from outside the organization.

Julian



> On Aug 13, 2020, at 9:27 AM, Maxime Beauchemin  
> wrote:
> 
> xposting from d...@superset.apache.org - what's the right place to post this
> for ASF-infra's attention?
> 
> ---
> 
> Hi all,
> 
> It just came to my attention that GitHub added a new "triage" access level
> at the repo level.
> https://github.blog/changelog/2019-05-23-triage-and-maintain-roles-beta/
> 
> In the past, we've identified that it was impossible for non-committers
> (especially our PMs and contributors-that-are-not-yet-committers) to help
> us triage issues, apply labels, assign reviews, close and reopen issues as
> needed. It's really clear to me that we really need all the help we can get
> in this area, and that not being able to involve more people into this
> process hurts us, and is a clear operational downside of using the ASF
> infra.
> 
> More technically, I think the way to make that easy and painless would be
> to add a new entry to the `.asf.yaml` file that would enable maintainers to
> assign the "triage" role to whoever they see fit. For reference, here's
> more context on that piece of automation I'd like to latch this onto here:
> https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features
> 
> Max


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

Giving our PMs and contributors triage rights on GitHub

[Maxime Beauchemin]

xposting from d...@superset.apache.org - what's the right place to post this
for ASF-infra's attention?

---

Hi all,

It just came to my attention that GitHub added a new "triage" access level
at the repo level.
https://github.blog/changelog/2019-05-23-triage-and-maintain-roles-beta/

In the past, we've identified that it was impossible for non-committers
(especially our PMs and contributors-that-are-not-yet-committers) to help
us triage issues, apply labels, assign reviews, close and reopen issues as
needed. It's really clear to me that we really need all the help we can get
in this area, and that not being able to involve more people into this
process hurts us, and is a clear operational downside of using the ASF
infra.

More technically, I think the way to make that easy and painless would be
to add a new entry to the `.asf.yaml` file that would enable maintainers to
assign the "triage" role to whoever they see fit. For reference, here's
more context on that piece of automation I'd like to latch this onto here:
https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features

Max