Maintenance

The Flint project tries to keep to a casual maintenance flow. We hold friendly conversations in the open on GitHub issues and try to gain consensus from team members on the best courses of action.

Issues Triage

When reviewing open issues, feel free to write your opinion on them and/or emoji: even if it’s just in agreement with what others have stated.

If an issue is still in its waiting period, add the status: in discussion label
Otherwise, if it’s ready to accept a PR, add status: accepting prs

Try to create an issue for any area of work that would qualify for a waiting period. This gives other team members a chance to learn about your intentions — especially newer ones ramping up on the project.

Pull Request Reviews

As with issues, pull requests should go through a waiting period before merge. Additionally, for nontrivial pull requests, please don’t merge until at least two team members have approved. If the pull request author is a team member, they count as one of the two approvals.

If you request changes on a pull request, add the status: waiting for author
- This label will be removed automatically if an author re-requests review
If you give a pull request its first approval, add the 1 approval label
- If the PR author is a team member, then go straight to ready to merge
Once a pull request has met the approval threshold, add the ready to merge label

Waiting for at least two team members’ approval helps the team feel ownership and stay informed about changes.

Changesets

When reviewing a pull request, please confirm the presence of a changeset if the pull request introduces a user-facing¹ change. If present, ensure the changeset is accurate and done at the appropriate version level (patch, minor, or major) based on the nature of the change. If a changeset is missing or inaccurate, please request that the author add or fix it before approving the pull request.

Waiting Periods

We leave nontrivial issues and pull requests open for some time following any significant change to give team members a chance to weigh in.

For anything clearly good and straightforward (e.g. small typo fixes, reproducible user-facing crashes, trivial dependency bumps, etc.) or high urgency (e.g. unblocking main build failures), no waiting period is necessary.
For anything really big (e.g. major re-architecture), wait 5 business days.
For anything else: wait 1 business day.

Use your best judgment and ✨ vibes ✨ for what category issues and pull requests fall under and what constitutes a significant change.

A user, in this context, is any consumer of any of the packages we publish, as well as users of the flint CLI. ↩