Gaps in maintenance coverage (Language Summit follow up)

[iritkatriel]

At the Language Summit session on the issues and PR backlog, we discussed the fact that people who submit issues and PRs sometimes receive no response, and have no way to know why their issue is not progressing. Could we communicate this better?

@nad pointed out that sometimes an issue remains open because there isn’t a core dev who wants to take ownership of it, for example when it relates to a module of the stdlib that is not actively maintained.

@willingc suggested that this be clearly flagged on the issue (for instance with a require-maintainer label or another agreed marking).

This opens the question of what should be done in this case. And, moving beyond the communication aspect - what is the process for growing a maintainer? A non core-dev cannot get reviews for PRs until there is a maintainer. How did we bootstrap maintainers in the past? What can we do to facilitate that in the future?

[guido (Guido van Rossum)]

Mentoring promising contributors into the triage role and eventually to commiters?

@Mariatta might have useful things to say about this.

[steve.dower]

I think it’s possible to bootstrap someone into an area you don’t know well if you (and they) are prepared to be really clear about:

• how the contributor determined that the fix is appropriate (correct, safe, compatible, etc.)
• test coverage is maintained/increased and doesn’t have any obvious gaps (even without being an expert in a module, it’s possible to assess this)
• the contributor actually sticks around and continues to care for the module, rather than disappearing

Given those, I’ll happily merge PRs into an area where nobody is claiming ownership. And this is the normal path to making someone a committer anyway.

[guido (Guido van Rossum)]

That sounds good, except there is no way that I know to assess the third point. Maybe we could encourage that after their PR is merged, but I don’t see how we can require it.

[brettcannon]

@iritkatriel

this be clearly flagged on the issue (for instance with a require-maintainer label or another agreed marking).

I think this sort of marker is important so other core devs also know that no one is planning to step forward to take something on (the usual psychological issue of thinking, “someone else will take care of this”).

Depending on how much automation we do, we could have a /notify pathlib and have that @ mention the folks listed as managing pathlib, and/or assign the issue to those people. And if there is no one for that area, we can add the require-maintainer and leave a comment that there is no specific core dev to help. Could remove the label if anyone assign themselves to the issue.

Using a label and a command string would also allow for searching the labelled issues to scrape out which areas seem to have the most number of orphaned issues. That would help direct folks to help out with orphaned areas.

[ezio-melotti]

@iritkatriel

How did we bootstrap maintainers in the past? What can we do to facilitate that in the future?

Personally, I became “maintainer” of a number of things by simply spending enough time working on them until I got familiar with the code and I felt confident in making changes.

The first issue I reported was about Unicode. I then learned (with the help of other coredevs, by reading the code, and by experimenting) how Unicode is implemented in Python, and then fixed a number of Unicode-related issues. While doing this I ran into issues with regrtest, learned how it worked, and improved that, and that also led me to learn more about unittest and fixing a number of unittest-related issues. Then I ran into problems with HTMLParser, and ended up updating the code to make it HTML5-compatible and able to parse every page without errors. Same with bpo and now GitHub.

I think other devs followed similar paths, even though many tend to focus on specific modules they care about and/or are already familiar with, possibly because of lack of time and/or interest.

In other words: have some issue → spend time understanding the code so you can fix it → fix the issue → fix related issues → you have now enough knowledge that you can become a maintainer.

@guido

Mentoring promising contributors into the triage role and eventually to commiters?

I’m actually not sure the path “contributors → triager → committer/maintainer” is always right. Being a triager requires a different set of skill than being a committer, even though there is certainly some overlapping.

A triager needs to be familiar with the way we classify issues, the issue tracker and its fields/labels, what is considered valid/invalid, know who the “experts” are, and have at least a basic understanding of how our code base is structured and organized. In theory they don’t even need to be developers at all (as long as they defer to the right person for more specific decisions).

A committer might be very familiar with a single module/package and have an understanding how our workflow, without necessarily having to be particularly familiar with the issue tracker and the rest of the codebase.

In other words, some contributors could be promoted directly to committers/maintainers, whereas other might be promoted to triagers and never become committers (unless they want to and are qualified enough).

@steve.dower

the contributor actually sticks around and continues to care for the module, rather than disappearing

I addressed this in Triaging/reviewing/fixing issues and PRs.

@brettcannon

I think this sort of marker is important so other core devs also know that no one is planning to step forward to take something on (the usual psychological issue of thinking, “someone else will take care of this”).

The bystander effect? This is part of the problem, however I think issues are ignored simply because devs are not willing to take the responsibility of merging a PR on piece of code they are not familiar with (and that’s completely understandable). Improving tests/coverage might be somewhat helpful.

@brettcannon

Depending on how much automation we do, we could have a /notify pathlib and have that @ mention the folks listed as managing pathlib, and/or assign the issue to those people.

We could use CODEOWNERS to track maintainers, and automate from there. Teams could also be created for module/packages that have multiple maintainers so that we could directly @mention them and add the teams as reviewers to PRs.

[pf_moore (Paul Moore)]

@ezio-melotti

We could use CODEOWNERS to track maintainers, and automate from there.

One problem with CODEOWNERS is that it has an implication of “ownership” (the clue’s in the name ) which in turn makes committing to be a codeowner feel like a bigger deal than simply having knowledge of the area. And it might put other people off as well, from a feeling that things should be left to the owner.

What would be useful IMO is a list of people who have knowledge on a subject - people you can ping for an informed opinion, without an implication that they will take responsibility for the issue. That would lower the barrier for people willing to help out in areas, as well as encouraging newcomers with a particular interest to ask for help while getting to a point where they feel they can call themselves an expert in a particular area.

EDIT: I’m not entirely sure how much this overlaps with the experts index (or how much the experts index overlaps with CODEOWNERS - maybe all that is needed is a clearer distinction between the two, and better explanations of what it means to be on the two lists).

[ezio-melotti]

@pf_moore

One problem with CODEOWNERS is that it has an implication of “ownership” (the clue’s in the name )

You are right – I suggested this because it was easily parsable, but it is probably not be the best option.

In another post I brought up the fact that we already have several lists of devs:

• a machine-parsable list in the voters repo (private)
• a machine-generated (from the list above) developers.csv (in the devguide repo)
• a machine-generated (from the csv above) developer log (in the devguide)
• a separately-maintained list of experts (in the devguide repo)
• a machine-generated (from the list of experts above) nosy-list autocomplete on bpo (no longer used)
• a separately-maintained translators list (in the devguide)
• a separately-maintained CODEOWNERS file (in the cpython repo)
• possibly others (e.g. release managers), more or less related to list of core devs

Ideally we would only have one (or two) human-friendly and machine-parsable lists that are used to generate the expert index, the developer log, CODEOWNERS, the list of translators, and possibly GitHub teams or whatever other notification mechanism we come up with to notify developers.

@pf_moore

What would be useful IMO is a list of people who have knowledge on a subject - people you can ping for an informed opinion, without an implication that they will take responsibility for the issue.

This is what the nosy-autocomplete did, but there is no direct equivalent on GitHub that works out of the box.

Edit: I created Machine-parsable developers list · Issue #848 · python/devguide · GitHub

[brettcannon]

@pf_moore

What would be useful IMO is a list of people who have knowledge on a subject - people you can ping for an informed opinion, without an implication that they will take responsibility for the issue. That would lower the barrier for people willing to help out in areas, as well as encouraging newcomers with a particular interest to ask for help while getting to a point where they feel they can call themselves an expert in a particular area.

But if no one is willing to take ownership it doesn’t matter how many informed people we have, the PR is still going to sit there waiting on a core dev to merge it. And if the PR doesn’t get reviewed and merged then no one will be able to evaluate if a new contributor is ready for increased responsibility.