Skip to content

docs: adjust review time expectations #3067

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 2 commits into
base: main
Choose a base branch
from
Draft

docs: adjust review time expectations #3067

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
aa97324
docs: adjust review time expectations
dimas-b Nov 17, 2025
edd4be0
review: more verbose review guidelines
dimas-b Nov 21, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
17 changes: 16 additions & 1 deletion CONTRIBUTING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -142,5 +142,20 @@ To ensure smooth collaboration and to maintain a high-quality codebase, please a
* `git log` can help you find the original/relevant authors of the code you are modifying. If you need, feel free to tag the author in your Pull Request comment if you need assistance or review.
* Do not re-create a pull-request for the same change. Use one Pull Request related to the same change(s). The purpose here is to keep the history and all comments in the Pull Request.
* Consider open questions and concerns in all comments of your Pull Request, provide replies and resolve addressed comments, if those don't serve reference purposes. If a comment doesn't contain `nit`, `minor`, or `not a blocker` mention, please provide feedback to the comment before merging.
* Give time for review. For instance two working days is a good base to get first reviews and comments.
* All changes to REST API specs should be accompanied by an email to the `dev` list for visibility.
* If you have the feeling that the discussions in a Pull Request are not going to a consensus, feel free to bring the discussion on the dev mailing list.

## PR Review Guidelines

* Smaller changes that are not likely to affect end users or downstream projects can be merged on
immediately on approval. If concerns are flagged later, they are to be addressed in follow-up PRs.
* Waiting at least two working days is recommented (even if the PR has approvals from some reviewers) for:
Copy link
Contributor

@adam-christian-software adam-christian-software Nov 21, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit (spelling): recommented -> recommended

- Refactorings that may affect downstream projects.
- Adding new features even if they are "off" by default.
* Three working days are recommended in these cases (even if the PR has approvals from some reviewers):
- Making changes to public classes or methods in `polaris-core`.
- REST API and user-level configuration changes (including feature flags).
- Adding new modules to the project.
* If concerns are raised during the initial review grace period, the PR should remain open until those
concerns are addressed. If a reviewer becomes unresponsive after raising a concern, and the same grace
period passes, the matter is to be discussed on the `dev` mailing list.