- Getting started
- Project & workspace
- Project description helpers
- Managing versions
- Adoption guidelines
- Best practices
- Frequently asked questions
- Edit your projects
- Generate projects
- Sign your apps
- Build schemes
- Scaffold files
- Lint projects
- Project graph
- Set up environment
- Generate secrets
- Clean the local environment
This document describes the framework that the organization follows to plan the work, as well as the strategy for triaging and prioritize issues that users create.
The backlog of tasks, work in progress, and completed tasks are represented on a project on GitHub.
The board is set up to move the tasks along the boards as the state of the PR or issue associated to the task changes.
When the release time comes, the content in the done board should be consistent with the content in the
The planning is done every Monday, Pedro from the core team decides what should go into the next release. The list should include those tasks that are high-priority, and a good balance between new features, improvements, and minor bug fixes. Doing only bug fixes is boring yet necessary, and doing only new features might make users feel unsupported.
After doing the planning, the to-do board should only contain those tasks.
Although there's a framework in place to make sure we tackle issues that are important for the users, contributors are welcomed to tackle other issues as well. Most of us devote our free time to the project so it's important that we spend that time on tasks that we find fulfilling.
Releases are done every Friday. Before proceeding with the release, the captain should share the CHANGELOG with the rest of the core team and get their approval. This is a good step to double-check if there’s important work that hasn’t been completed yet and that would be great to include in the release. What goes into the release is ultimately the captain’s decision, but they should aim to find a consensus with the rest of the team.
Once the release is done, all issues should be closed and the tasks from the done board archived.
It’s everyone’s responsibility to help with triaging. The goal of triaging is twofold. First, we need to categorize the issue accordingly using labels. That makes it easier to filter and search for issues in the future. Second, we need to set the right priority to help prioritize them accordingly. Only issues that either are impacting a lot of users or are blocking users should be considered high-priority. High-priority issues should be moved straight to the weekly backlog, and prioritized over the other tasks.
As part of triaging, it’s also important to make sure that the issues have enough context for debugging. We should encourage users to follow our reporting bugs guidelines and include a reproducible test case.
After labeling the issues and ensuring they contain all the context necessary for debugging, we should post a comment thanking the user for reporting it, and setting some expectations on when we think it’ll be fixed. This is a subtle action that helps build strong connections with the users.