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 <maximebeauche...@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 <pot...@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 <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 > > > > > > > > -- Matt Sicker <boa...@gmail.com>
