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 <jhyde.apa...@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 <maximebeauche...@gmail.com> > > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
