Skip to content
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.

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

Require 24 hour minimum time for PR reviews #304

Open
nyalldawson opened this issue Oct 8, 2024 · 1 comment
Open

Require 24 hour minimum time for PR reviews #304

nyalldawson opened this issue Oct 8, 2024 · 1 comment

Comments

@nyalldawson
Copy link
Contributor

nyalldawson commented Oct 8, 2024

QGIS Enhancement: Require 24 hour minimum time for PR reviews

Date 2024/10/24

Author Nyall Dawson

Contact nyall dot dawson at gmail dot com

Summary

This QEP proposes a change to policy to permit pull request merging only after a minimum 24 hour open-for-review period. (Currently, a PR can be merged immediately, as soon as a core developer has approved the PR)

This QEP is part of a series of proposals designed to improve the QGIS development workflow and document existing policies.

Proposed Solution

Currently, for an developer with commit rights to the QGIS repo to get a pull request merged, they must:

  1. Ensure that the PR passes all reasonable CI checks (some exceptions exist to this rule, eg when a check is broken for unrelated reasons (such as broken third party services, or a lint/code analysis/spell check test failing from other parts of a modified file).
  2. The PR must be approved by a different developer with core commit rights

This proposal would add an additional policy:

  1. A PR must remain open for at least 24 hours following submission, even if it has already been approved. This is to allow wider feedback to be gathered prior to merge, and to permit pre-merge feedback from developers in other time zones. Exceptions to this policy are:
    • Approved pull requests for backports to stable branches
    • "Emergency" pull requests, eg those which fix broken master builds, CI infrastructure or which represent a time-sensitive security risk
    • Trivial fixes. The definition of "trivial" is left open to common sense and developer discretion, but is expected to include non-risky changes like typo fixes, translation string fixes, tab order changes, or similar.

Possible workflow

We could possibly use the "minimum open time" GitHub action to enforce this policy. See https://github.com/gregsdennis/minimum-open-time.

An example repo using this action is https://github.com/json-schema-org/json-schema-spec

rouault added a commit to rouault/QGIS-Documentation that referenced this issue Oct 10, 2024
rouault added a commit to rouault/QGIS-Documentation that referenced this issue Oct 10, 2024
@rouault
Copy link
Contributor

rouault commented Oct 10, 2024

I've created a doc pull request capturing this: qgis/QGIS-Documentation#9300

rouault added a commit to rouault/QGIS-Documentation that referenced this issue Oct 10, 2024
DelazJ pushed a commit to qgis/QGIS-Documentation that referenced this issue Nov 7, 2024
qgis-bot pushed a commit to qgis/QGIS-Documentation that referenced this issue Nov 7, 2024
DelazJ pushed a commit to qgis/QGIS-Documentation that referenced this issue Nov 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants