You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by Maxime Beauchemin <ma...@gmail.com> on 2020/08/13 16:27:29 UTC
Giving our PMs and contributors triage rights on GitHub
xposting from dev@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
Re: Giving our PMs and contributors triage rights on GitHub
Posted by Justin Mclean <ju...@classsoftware.com>.
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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Giving our PMs and contributors triage rights on GitHub
Posted by Tomasz Urbaszek <tu...@apache.org>.
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 <ma...@gmail.com> wrote:
> xposting from dev@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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: Giving our PMs and contributors triage rights on GitHub
Posted by Sheng Zha <zh...@apache.org>.
+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 <ma...@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 <ju...@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
Re: Giving our PMs and contributors triage rights on GitHub
Posted by Maxime Beauchemin <ma...@gmail.com>.
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 <ju...@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
>
>
Re: Giving our PMs and contributors triage rights on GitHub
Posted by Justin Mclean <ju...@classsoftware.com>.
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
Re: Giving our PMs and contributors triage rights on GitHub
Posted by Matt Sicker <bo...@gmail.com>.
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 <ma...@gmail.com>
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 <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.
>
>
>
> Max
>
>
>
> On Fri, Aug 14, 2020 at 5:17 AM Jarek Potiuk <po...@apache.org> 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 <jh...@gmail.com> 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&list=PLGudixcDaxY3RGLSlWoN_cEEXhIT1OPmj&index=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 for commercial ones - but it
> never
>
> > hurts to have someone who watches how the whole organisation works,
>
> > organizes regular retrospectives, and "catalyses" the improvements in the
>
> > way people cooperate - and being able to organize and manage projects
>
> > issues (together with the developers) is a super important part
>
> > of this.
>
> >
>
> > > 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.
>
> > >
>
> >
>
> > Again just to reiterate. It's the same with engineers/developers. Most of
>
> > them can do this, but a few cannot. I see no reason whatsoever why
>
> > "business" people would be inferior here. It's all matter of personal
>
> > integrity in my opinion, not the role people have in organisation.
>
> >
>
> > > 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.
>
> >
>
> > True - but those kind of projects are already in a bad shape. I think if
>
> > that's the case, the company (not business people!) has already enough
>
> > influence on the project. And again - I do not feel comfortable with
>
> > "business people" from the company being inferior than "developers". So
> for
>
> > me this whole point is rather superficial.
>
> >
>
> > > Julian
>
> > >
>
> > >
>
> > >
>
> > > > On Aug 13, 2020, at 9:27 AM, Maxime Beauchemin <
>
> > maximebeauchemin@gmail.com> wrote:
>
> > > >
>
> > > > xposting from dev@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-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
>
> >
>
> >
>
> --
Matt Sicker <bo...@gmail.com>
Re: Giving our PMs and contributors triage rights on GitHub
Posted by Maxime Beauchemin <ma...@gmail.com>.
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 <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.
Max
On Fri, Aug 14, 2020 at 5:17 AM Jarek Potiuk <po...@apache.org> 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 <jh...@gmail.com> 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&list=PLGudixcDaxY3RGLSlWoN_cEEXhIT1OPmj&index=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 for commercial ones - but it never
> hurts to have someone who watches how the whole organisation works,
> organizes regular retrospectives, and "catalyses" the improvements in the
> way people cooperate - and being able to organize and manage projects
> issues (together with the developers) is a super important part
> of this.
>
> > 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.
> >
>
> Again just to reiterate. It's the same with engineers/developers. Most of
> them can do this, but a few cannot. I see no reason whatsoever why
> "business" people would be inferior here. It's all matter of personal
> integrity in my opinion, not the role people have in organisation.
>
> > 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.
>
> True - but those kind of projects are already in a bad shape. I think if
> that's the case, the company (not business people!) has already enough
> influence on the project. And again - I do not feel comfortable with
> "business people" from the company being inferior than "developers". So for
> me this whole point is rather superficial.
>
> > Julian
> >
> >
> >
> > > On Aug 13, 2020, at 9:27 AM, Maxime Beauchemin <
> maximebeauchemin@gmail.com> wrote:
> > >
> > > xposting from dev@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-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
>
>
Re: Giving our PMs and contributors triage rights on GitHub
Posted by Jarek Potiuk <po...@apache.org>.
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 <jh...@gmail.com> 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&list=PLGudixcDaxY3RGLSlWoN_cEEXhIT1OPmj&index=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 for commercial ones - but it never hurts to have someone who watches how the whole organisation works, organizes regular retrospectives, and "catalyses" the improvements in the way people cooperate - and being able to organize and manage projects issues (together with the developers) is a super important part
of this.
> 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.
>
Again just to reiterate. It's the same with engineers/developers. Most of them can do this, but a few cannot. I see no reason whatsoever why "business" people would be inferior here. It's all matter of personal integrity in my opinion, not the role people have in organisation.
> 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.
True - but those kind of projects are already in a bad shape. I think if that's the case, the company (not business people!) has already enough influence on the project. And again - I do not feel comfortable with "business people" from the company being inferior than "developers". So for me this whole point is rather superficial.
> Julian
>
>
>
> > On Aug 13, 2020, at 9:27 AM, Maxime Beauchemin <ma...@gmail.com> wrote:
> >
> > xposting from dev@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-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
Re: Giving our PMs and contributors triage rights on GitHub
Posted by Julian Hyde <jh...@gmail.com>.
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 <ma...@gmail.com> wrote:
>
> xposting from dev@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-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org