Community members would make great triagers

[danmoseley]

Some repos have successfully shared triage rights with community members

• dotnet/iot does this at a public triage meeting, and gave the Github triage role to one community member so far (@pgrawehr) , and reached out to another. Per @richlander this has been a good experience.

• dotnet/roslyn has given a small number of community members the Github triage role (which allows add/remove labels and closing issues). These folks have helped identify duplicate issues, clarified issues, and helped route and prioritize. @jinujoseph felt this was super useful. They currently ask these triagers to not close issues unless they are duplicates.

The rustlang project uses 'triage bot' instead of assigning the Github role. We should take a look at that.

We should determine what we can learn from this.

todo -- @terrajobst will follow up with to find out whether there's general guidelines.

[jeffwilcox]

This is great to hear! Successful projects take input from throughout the community and the opportunity to receive triage/maintainer/etc. access is an excellent route.

[terrajobst]

@terrajobst will follow up with to find out whether there's general guidelines.

After talking to a few folks, we don't see any issues with giving externals triage permissions. In fact, we believe this is the way to build community. People who earn the trust of the project maintainers should be given more powers. In the projects we do this, we've found that this helps maintainers with the busy work and people are lurking around all the time feel their support is rewarded & makes a difference.

[danmoseley]

@333fred could you share Roslyn's experience, the approach you took and what you learned?

[333fred]

Sure. We've given a very small set of particularly active contributors triage access in a couple of repositories now: dotnet/csharplang, and dotnet/roslyn. The particular community members we chose (3 in csharplang, 5 in roslyn) had a long history of positive community interaction, and that we felt that they would be able to both well represent the broader .NET community and uphold the highest standards of our Code of Conduct. We also have a private teams chat for us to discuss conduct and other issues that would need to be done in a private conversation, as needed.

The experience has been super positive, particularly in the csharplang repository, where I need to give special credit to @YairHalberstadt for helping us drive down the number of open issues from well over 1,000, many of which were duplicates, incomplete, or not really issues, to 420 open issues that are mostly high-enough quality for the LDT to look at. I can honestly say that the quality of the repository and the interactions with the rest of the community have markedly improved since we implemented this. In the roslyn repo, contributors have been especially helpful in routing bugs, closing duplicates, and flagging higher-priority items. This last bit, in particular, has been especially useful and is not easily done by bot systems. These contributors were often basically doing this job before we added them as triagers, and @jaredpar had expressed that often he'd just look to see what a community member had said about the bug then just do what they said to do (close as duplicate or use their feedback to decide what milestone the bug needed to go in).

[danmoseley]

@YairHalberstadt do you have any thoughts to share about the experience from the community point of view? If we were to do something similar in another large repo, would you recommend we do anything differently?

[333fred]

I'll also tag our other contributors @jnm2, @svick, @alrz, and @youssef1313 for their thoughts.

[YairHalberstadt]

@danmoseley

I can't think of anything that required changing really. The most tricky part was hashing out which issues should be closed, which should be moved to discussion, and which should stay as is, but we worked that out on a case by case basis over the teams chat, and by the end I had a pretty good idea.

On a separate note the teams app did not work well for me at all, and often due to a bug in teams I couldn't access the community contributors group at all, but I understand there's not really much the dotnet team can do about that.

Finally at the moment I've recently moved jobs and now have much less free time (turns out my OSS contributions were directly proportional to how bored I was at work), and I feel embarrassed about how little I'm doing on either community. If the team wants to limit the total number of community contributors they may want to consider rotating them around as new promising candidates appear.

[pgrawehr]

Of course, Teams calls with too many people won't work well or will be inefficient, but I guess that problem can be solved once it arises (maybe by separating the call into several for different topics). The dotnet/iot team is small, but even then it rarely happens that everybody can join. Most calls have only like 4 people in them (out of I think 8 that are invited).

[danmoseley]

@richlander @HongGit @zkat met, and also chatted with @eiriktsarpalis , and we had these thoughts for an experiment in dotnet/runtime:

What would be the value to maintainers?

1. Enabling community to feel more included/engaged and increase transparency in how we make decisions
2. Help triage be more efficient and responsive
3. (Lower priority) Building confidence and expertise in individuals eg to grow regular committers.

What would be the value to community members?

1. Making easier something they are already passionate about
2. Giving them more influence over the direction of the product and quality
3. Career building -- item on resume
4. Offering deeper access to the product team, and opportunity to build expertise.
5. Public recognition (similar to folks who offer PR's) including list on area owners page, and possibly on the release blog page under the code contributors

Triager responsibilities

1. Route issues (ie., fix area labels)
2. Ask for more info (eg., help clarify repro steps)
3. Identify related issues and duplicates (and close the obvious duplicates)
4. Ad hoc offer input into prioritization
5. Help communicate our backlog and prioritization to others in the community. (dotnet/iot repo achieve this with access to a triage group that meets Thursdays)

Triager non responsibilities

1. Make prioritization decisions (eg., set milestone or close as out of scope) although their input is welcome and encouraged and the experiment could evolve.

Maintainer reponsibilities

1. Be engaged and keep them informed and offer recognition.
2. Provide a point of contact among maintainers and reach out often (eg email, Teams, Discord etc)
3. If requested, configure the labeling bot to notify them of labels interesting to them if they wish.
4. If all parties wish, we could bring them into area owner triage calls. This is the dotnet/iot model. Note not all areas do such calls. For the responsibilities above, it shouldn't be necessary, but it may be interesting!

How to select folks

• Do we pick folks, or ask for expressions of interest. Decision: we try picking. this is what was done in dotnet/roslyn and dotnet/iot.
• How many are we looking for? We agreed to start small - say, 3 in the repo.
• We are looking for folks with (a) history of engagement in the repo one way or another (b) knowledge and interest in one or more of our areas (c) friendly! (d) willing and interested!
• Identify champ for each person - the one who proposed them, perhaps - and give some guidance about communication.

Next steps

• Draft plan, get internal consensus (M2's, Jamshed, …)
• Email internal repo contributors alias to collect suggested names (explaining responsibilities of mentor)
• Pick a small number and reach out until we have 3 agree to do it
• If requested, update notification bot.
• We don't need an announcement as this is pretty limited.

Future directions

• Would triagers specialize in an "area"? A: We assume this will happen naturally, based on interests.
• Better document what we do -- our process, our bar, how we prioritize. Although, we aren't necessarily consistent today, and we aren't asking triagers to prioritize at this point.

Risks/mitigations

• If folks lose interest/don't participate
• Creating an excluding "in group"

[eiriktsarpalis]

The rustlang project uses 'triage bot' instead of assigning the Github role. We should take a look at that.

FWIW here's an instance of a user asking for something like that to help us out.

[danmoseley]

@eiriktsarpalis perhaps worth creating an issue for a triage bot specifically? We can look around for other prior art, and consider whether to give it a trial and where, and what that would take.

[danmoseley]

3 community members have now accepted the role of triager in dotnet/runtime repo. They will each have a contact in the product team, and figuring out how things will work. Expect them to get rights within the next week and figure out parameters and announce broadly within the next couple weeks.

We'll record here what we learn and how it goes.

[vishalmsft]

3 community members have accepted the triager in dotnet/wpf. Expect them to get right with next 1-2 weeks. @gurpreet-wpf is working on announcement and work with them to share the responsibility information.

[eiriktsarpalis]

FWIW I'm seeing considerably more activity now from dotnet/runtime community triagers compared to the initial months of the experiment. Folks tend to be cautious initially while learning the ropes so active encouragement and coaching is probably necessary even after permissions have been granted.