-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
Instructions for making PR passes
The purpose of making manual passes over PRs is two-fold:
- To give a human touch to the PR process.
- To decrease the number of open PRs.
As of this writing, Oppiabot has been in operation for about 2 years with the goal of automating most of the processes that used to be done by the former maintainer's group on a weekly basis. However, replacing a human with a bot resulted in decreased "warmth" in the review process and more PRs were being closed rather than being completed. After the dev workflow lead resumed the process of manually reviewing PRs, PRs were being completed faster, and fewer were closed. Therefore, the community should strive to have a human in the review process as much as possible.
The purpose of the rotation is to gauge the health of the community and the PR process, it is not to take over the responsibility of checking PR health. At the end of completing all of the steps below, you should be able to:
- Gauge the overall wellbeing of the community.
- Know the current responsibilities of individuals.
- Determine what dev workflow support the community requires.
Goal: Move all PRs forward so that they aren't stale and ensure that the assignee field is accurate. Most importantly, to ensure that contributors aren't stuck (since some may not ask for help when they need it). On Github:
Collect the following pieces of information from the PR:
-
Whether there’s a “First-time contributor” label on the PR.
-
Check all the assignees of the PR.
- Go through the thread and check the last date of their assignment.
-
Check if the PR has the LGTM label.
-
If it’s a first-time contributor’s PR
- If the author hasn’t followed any OppiaBot’s comments, then explain that comment and ask/help them to follow it. [e.g, New contributor doesn’t have rights to add a label to the PRs, help them by adding a label to the PR]
- If they have pushed changes but not replied/assigned/pinged any reviewers:
- Ask the contributor to follow the instructions provided on the wiki page. (and if possible write the important instructions explicitly.)
-
If a contributor (including the author) is assigned for at least 2 days, then:
- @-mention the contributor that they should take action or reach out if they have questions. [Asks contributors to follow the process (like follow Oppia bot comments) with a wiki link instead of just writing the step.] Note: If the reviewer has left a comment and has forgotten to assign the author and unassign themselves, ping them and ask them to do so. Note: If the contributor did not respond to the last ping, do not @-mention the contributor again, let Oppiabot automatically close the PR.
-
If the PR has LGTM label but tests failed, then:
- Check that the tests are not flaky, if so, restart them.
- If the tests are not the result of flakiness, @-mention the author that tests failed.
-
If the PR has an LGTM label and all tests pass, then:
- Check that there are no outstanding comments
- If there are none, then merge the PR.
- Check that there are no outstanding comments
At the very end, ensure that no one contributor has too many open PRs (ie. over 3), if so, please encourage them to complete those PRs before opening new ones. Also, if there is a reviewer with a lot of PRs assigned to them, then it's worth starting a conversion whether the reviewer needs to focus their code ownership. Finally, if there are any community-wide issues, please let the community and core maintainers know.
Have an idea for how to improve the wiki? Please help make our documentation better by following our instructions for contributing to the wiki.
Core documentation
- Oppia's mission
- Code of Conduct
- Get involved!
- How to report a bug
- Google Summer of Code 2024
- Hacktoberfest 2024
Developing Oppia
- FAQs
- How to get help
- Getting started with the project
- How the codebase is organized
- Making your first PR
- Debugging
- Testing
- Codebase policies and processes
- Guidelines for launching new features
- Guidelines for making an urgent fix (hotfix)
- Testing jobs and other features on production
- Guidelines for Developers with Write Access to the Oppia Repository
- Release schedule and other information
- Revert and Regression Policy
- Privacy aware programming
- Code review:
- Project organization:
- QA Testing:
- Design docs:
- Team-Specific Guides
- LaCE/CD:
- Developer Workflow:
Developer Reference
- Oppiabot
- Git cheat sheet
- Frontend
- Backend
- Backend Type Annotations
- Writing state migrations
- Calculating statistics
- Storage models
- Coding for speed in GAE
- Adding a new page
- Adding static assets
- Wipeout Implementation
- Notes on NDB Datastore transactions
- How to handle merging of change lists for exploration properties
- Instructions for editing roles or actions
- Protocol buffers
- Webpack
- Third-party libraries
- Extension frameworks
- Oppia-ml Extension
- Mobile development
- Performance testing
- Build process
- Best practices for leading Oppia teams
- Past Events