Skip to content

Latest commit

 

History

History
75 lines (59 loc) · 4.35 KB

PROCESS.md

File metadata and controls

75 lines (59 loc) · 4.35 KB
Raw

The Process

This file contains some process notes for FerretDB Inc. engineers and long-term contributors. If you are a community contributor, feel free to ignore all this! We will do all that for you so you can focus on what is really interesting for you.

This guide tries to be short and does not mention things that are completely automated by our tooling.

Showing progress

We want our work to be visible and transparent. This way we can help each other and make sure that we are on the right track. To uphold these principles, we agree to make results of our daily work available for others through various means such as pull requests, code reviews, created issues, or any other relevant method.

Community

We expect issues picked up by the community to be done in about two weeks. After about a week of inactivity, we should ping contributors.

Pull requests

For FerretDB Inc. engineers and long-term contributors, besides the guides in CONTRIBUTING.md, please follow these notes below when you working with pull request:

  1. Send pull requests from forks; do not make personal branches in the main repository. This way, we are similar to community members and could notice similar problems that we could fix for everyone, not just for us.
  2. Pull request title should be accurate and descriptive as it is used in the generated changelog. It generally should start with imperative verb ("Fix …", not "Fixing …", "Fixed …" or other forms). It should not mention the issue number.
  3. It is fine to send several sequential pull requests for one issue to make them easier to review. In that case, please still use the Closes word as described in CONTRIBUTING.md (because words like "refs" do not link PR to the issue), but don't forget to reopen the issue once PR is merged, but the issue as a whole is not done.
  4. Please create a draft pull request as soon as you start working on an issue; that is needed for our process tooling. Once it is ready for review, please mark it as such. After that, there is no need to switch between draft and non-draft states.
  5. Pull requests should be merged by an auto-merge that the author should enable. If the pull request is not ready to be merged for some reason (but ready to be reviewed as usual), the description should explain why, and the do not merge label should be applied. Even in that case, auto-merge should still be enabled by the author.
  6. Autogenerated GitHub's squash commit's body should be manually replaced by Closes #<issue_number>. with optional trailers for co-authors.
  7. Ultimately, the author is responsible for doing everything to ensure that the pull request is merged and done.

One can see all pull requests that await review there. We also have #devlog channel in our community Slack with periodic reminders. To make them useful, talk with @GitHub bot in direct messages to link your Slack and GitHub identities, and then configure notification only for your name.

Test scripts

Pull requests that add temporary test.js test scripts have slightly different rules:

  1. The title should start with "Add test script for".
  2. The descriptions of both PR and issue should link to each other.
  3. Commits must change only the test.js file.

Once PR with a test script is sent and verified by someone else, it is closed. Once the linked issue is resolved, the PR should be reopened and merged with main to confirm that the test script pass now. Then it should be closed again.

Creating issues

  1. Please use Chore type instead of Enhancement or Feature (but not Bug) because its template is much more useful (but may be too daunting for regular users, that's why templates for enhancements and features are much simpler). After creating an issue, please change its type (label) manually.
  2. Do not change other automatically applied labels, assignees, or projects.