-
-
Notifications
You must be signed in to change notification settings - Fork 3.8k
Triaging process
This wiki outlines the steps to triage new and existing issues. This ensures that all issues are being effectively tracked and prioritized.
The Dev Workflow team lead (currently Chris) should do the following every week for any filed issues that aren’t assigned to a project:
- Check that the issue is written clearly enough. Request clarification if needed.
- Assign the issue to the appropriate task force, if applicable. Otherwise, assign it to the relevant team (LaCE, CD, Dev Workflow) based on which type of user it affects.
- If you’re not sure how to categorise an issue, feel free to ping Sean (@seanlip) for help!
Team leads should do an audit every week to categorise new issues in their GitHub Projects board, following these steps:
-
Verify that the issue lies within the scope of the team (see definitions below).
- If not, assign the issue to the appropriate project/team.
-
Determine whether the issue is a bug or a enhancement
- If the issue is a feature request (enhancement), contact the relevant PM (product manager) for the team and ask them to take a look and decide whether it needs to be worked upon. (See the list of PMs below.)
- If the issue is a bug, add the Bug label.
-
(For simple UI issues) Make sure the bug is reproducible
- The issue should be consistently reproducible on either develop or the test/backup server.
- If that isn’t the case, ask the issue author for clarity.
- If the issue is not a simple UI bug that can be easily verified, the task of verifying the reproducibility lies on the developer working on the issue.
-
Once the Bug or Enhancement label has been added, the team lead should add the appropriate ‘Impact’ label (asking the PM or tech lead for help if they’re not sure), as well as the appropriate ‘Work’ label to the issue.
-
‘Impact’ defines how much the issue affects the functionality of the user-facing features. There are 3 associated labels: Impact: High, Impact: Medium and Impact: Low. For example, the issue is considered to have a high impact if it breaks a critical feature or blocks a release. General bugs (non-blocking) and improvements can be considered to be of medium impact while issues that occur in a few edge cases or affect a small number of users are issues with a low impact.
- Severity:
- Severe: Blocks or represents a primary user journey – e.g. end user playing a lesson, developer installing Oppia.
- Moderate: blocks or represents a secondary user journey – e.g. end user changing a profile picture, developer easily seeing the output of frontend tests at the bottom of the CI log.
- Minor: Neither of the others, relates to “polish”.
- Severity:
-
‘Work’ defines how hard it would be to solve/resolve a particular issue. This is generally correlated with the amount of ambiguity in the task. We use the following rough system for assigning this label:
- Work: Low: Solution is clear and broken into good-first-issue-sized chunks.
- Work: Medium: Otherwise, if the means to find the solution is clear.
- Work: High: Everything else.
-
-
Once the appropriate ‘Impact’ and ‘Work Required’ labels has been added, determine its severity and assign the fitting priority label based on its impact (and possibly the work required label)
-
If the issue is a high-impact bug, put it in the high-priority bucket and prioritise it within the team.
-
For the priority bucket, team leads should include “important” issues – typically, a selection of high-impact enhancements and low-work medium-impact bugs – while keeping the size of that bucket about 2-3 times the projected stable number of team members.
[!TIP] This exercise might also help determine how large the team needs to be.
-
Other issues go in the ‘backlog’ bucket.
-
Any issue with an external dependency that the team cannot resolve by itself (example: missing mocks) goes in the ‘blocked’ bucket, and the reason should be specified in the ‘Issue specific status’ field (using free-text). Team leads should ensure an issue spends as little time here as possible.
-
-
Determine if the issue is potentially a good first issue
- If the issue seems like something a new contributor to Oppia can take up, make sure to add enough information in the issue description for a new contributor to start work on that issue then ask Sandeep or Vojta to add the Good First Issue label. (Note: typically these are “Work: Low” issues.)
- For such good first issues, also assign purple “technology: TypeScript”, “technology: Apache Beam”, “technology: Python”, etc. labels as appropriate. This helps new contributors identify issues that they would find approachable.
- If the issue seems like something a new contributor to Oppia can take up, make sure to add enough information in the issue description for a new contributor to start work on that issue then ask Sandeep or Vojta to add the Good First Issue label. (Note: typically these are “Work: Low” issues.)
-
After triaging all issues, make sure the issues in the 'Priority' and 'High Priority' buckets are sorted based on severity/priority (high to low).
-
LaCE Quality:
- Learners: Diana (@dchen97)
- Creators: Sean (@seanlip)
-
Contributor dashboard:
- Diana (@dchen97)
-
Dev workflow:
- Chris (@U8NWXD)
-
Android:
- Sean (@seanlip)
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
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 oppia/oppia
- 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