OpenCraft Core Contributors Call for Proposals: Summit to Enhance the Core Contributor Experience

Discussions - Public
,
15

@kshitij and I would like to submit a proposal for the Improve Review Processes category, addressing these two challenges in particular:

  • Finding reviewers
  • Review pace (or lack thereof)

We’d essentially approach this from three different angles. Here are the ideas we collected:

#1: Making it easier for PR authors (including but not limited to CCs) to manage their own PRs.

Simplifying the OSPR welcome message

As discussed recently on the Open edX forum, the repetitive value of the message is quite low. If you’re already familiar with the OSPR process the message has very little value, and some of the important information about who maintains the parent repository is buried in the message.

By collapsing individual sections of the message it should be possible to simplify it quite a bit, and key information could be highlighted better by putting it at the front of the message.

Simplifying documentation about the kinds of PRs that need product review

When following the current link for checking the list of PRs that need product review from the OSPR welcome message, it’s not immediately clear where the list is. It lives in a collapsed section on top of the target page. It would be helpful to be able to see the list right away, and for it to include a few example PRs that do and don’t require product review.

CC @cassie @Ali

#2: Making it easier for CCs to help with PR reviews.

  • Some level of automated assignment of PRs might help. A bit of bystander effect can always set in, if everyone thinks it’s someone else’s responsibility. We could have every PR automatically be assigned to the maintainer(s) of the parent repo. They could then self-request a review or, if necessary, request a review from someone else (which would help spread the responsibility to other CCs). We could at least trial this approach with a willing maintainer and see how it goes.

  • We have special views on the Contributions board that list OSPRs in need of a reviewer (all OSPRs, edx-platform only). There was a one-time announcement about these views at some point; however by now, the visibility of that announcement probably isn’t great, especially for new CCs. In order to make CCs aware that they can just go to those views, pick one or more PRs, and assign themselves as reviewers, we’d suggest that the onboarding course for CCs (and/or related onboarding documentation) be updated to include pointers about where to find PRs to pick up for review.

#3: Automating additional parts of the OSPR management process to increase the number of OSPRs that OSPR managers can process.

Making CC info for individual repos easily discoverable

In the context of BB-9084 there’s been some recent discussions on the Open edX forum and on GitHub about this topic.

One way to approach this would be to create some simple tools to get the current set of CCs for a repo, and list/order them based on a few simple factors: parent organization, number of PRs they’re currently reviewing, etc. With this info it would not only be possible to quickly identify the entire pool of potential CC reviewers for a PR, but also to determine which of them might be in the best position to pick up the review right now.

Another way would be to try and integrate CC info directly into the Contributions board (which is the main tool OSPR managers use for triage).

In line with @navin’s suggestions above, we could also consider leveraging things like the CODEOWNERS file. Since that file allows us to map parts of the code in a repository to who “owns” that bit of code, utilizing it might be especially helpful when it comes to determining who would be the best reviewer for a specific PR that has been opened against a big repo like edx-platform.

(There are tools to auto-generate these kinds of files like GitHub - open-sauced/pizza-cli: A CLI for all things OpenSauced, however, this kind of automation might not be a great idea for a project like Open edX.)

Manual OSPR management tasks to automate

Managing labels
  • Automatically set the core contributor label upon PR creation.
    • This will require getting a global list of CCs (even if someone is not a coding CC for one or more repos, they could still open a PR), maybe from the Core Contributors to the Open edX Project wiki page, and checking whether the PR author is on that list.
  • Automatically remove obsolete labels when a PR gets merged:
    • blocked by other work
    • changes requested
    • inactive
    • needs maintainer attention
    • needs more product information
    • needs rescoping
    • needs reviewer assigned
    • needs test run
    • waiting for eng review
    • waiting on author
  • Automatically remove obsolete labels when a PR gets closed:
    • needs maintainer attention
    • needs reviewer assigned
    • needs test run
    • waiting for eng review
    • waiting on author
Managing metadata for the Contributions board

  • Retrieve OSPR creation date from GitHub and use it to automatically populate the Date opened field. (Ideally, this would also be done for platform roadmap tickets.)

  • Retrieve maintainer info from catalog-info.yaml (just like we’re already doing for the OSPR welcome message) and use it to automatically populate the Repo Owner / Owning Team.

    • For repos maintained by specific individuals, include both their full name (if available) and their GitHub handle, e.g. Brian Mesick (@bmtcril).
    • As a side note, “Repo Owner / Owning Team” terminology is outdated at this point. “Maintainer(s)” or “Maintaining Team(s)” would be more appropriate (as it would better reflect current practices). We should consider renaming the field.

  • We could consider introducing a Date merged/closed field and automatically populate it with data from GitHub as well.

    • This might help us identify repositories whose time-to-merge is particularly high (though checking for the number of long-running PRs and/or looking at data from the Maintainer Pull Request Reporting dashboard could give us a sense of that as well).
Managing board statuses
  • Automatically change the status of a PR from Needs Triage to Waiting on Author on the Contributions board if the PR is marked as draft upon creation.
2 Likes