[QGIS-Developer] [Qgis-psc] Official PSC call on pull request policies

Andreas Neumann andreas at qgis.org
Sun Feb 25 23:10:24 PST 2024


Hi,

We will discuss this at our PSC meeting on Tue 5.

Greetings,
Andreas

On Mon, 26 Feb 2024 at 00:21, Nyall Dawson via QGIS-PSC <
qgis-psc at lists.osgeo.org> wrote:

> Hi PSC,
>
> I would love for an official call to be made on which of two
> conflicting pull request queue management policies should be adopted
> by QGIS.
>
> There are currently two proposals, and the lack of a formal policy is
> causing confusion/conflict in how pull requests are managed.
>
> Policy #1: https://github.com/qgis/QGIS/pull/56062
>
> In short, Sandro proposes that the pull request queue be an open queue
> of ALL work happening everywhere, in any state of completeness. Pull
> requests are permitted for semi-complete work, and for long-term
> (including multi-year) projects which are not yet ready for review or
> merge. The justification here is that having this work open in the
> queue makes it widely visible and so that other developers are aware
> of ongoing work across the community.
>
> Currently, these pull requests will be auto-closed by stalebot due to
> the lack of activity on the ticket. Sandro's proposal is to disable
> stalebot handing of draft / WIP pull requests, and effectively to
> formalise that the queue is a valid place for work of this nature and
> status.
>
> (@strk please expand here if you feel I haven't summarised your point
> of view correctly!)
>
> Policy #2: https://github.com/qgis/QGIS/pull/56523
>
> In this PR I propose to set a formal policy that draft and WIP pull
> requests are NOT suitable for opening against the QGIS repository.
>
> My justification is that we have a long-standing issue with
> maintainability of the pull request queue, and anything which
> decreases the signal-to-noise ratio on open tickets is undesirable.
> When the queue includes work which is not ready for review, then it
> becomes very tricky to work out the actual status of pull requests and
> which ones should be focused on during review time. (Effectively right
> now we have a situation where any pull request which is pushed on the
> 2nd page of requests will basically NEVER get reviewed, as there is a
> constant stream of ready-for-review work flowing into the first page
> and the signal-to-noise ratio of ready-for-review/merge PRs on
> subsequent pages is extremely low). I do not believe it is fair for
> submissions like https://github.com/qgis/QGIS/pull/55172 or
> https://github.com/qgis/QGIS/pull/55293 where reviews take SUCH a long
> time, and it is my belief that by keeping the queue as small as
> possible and avoiding WIP/draft work we will increase the likelihood
> that PRs like these can be reviewed more quickly in future.
>
> Please note that there is considerable discussion on
> https://github.com/qgis/QGIS/pull/56062 already which should be read
> when reviewing this decision.
>
> Can I ask that PSC choose one of these two policies to formally adopt
> so that there is no misunderstanding or conflict in future?
>
> Thanks in advance!
> Nyall
> _______________________________________________
> QGIS-PSC mailing list
> QGIS-PSC at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/qgis-psc
>


-- 

--
Andreas Neumann
QGIS.ORG board member (treasurer)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20240226/05f17a01/attachment.htm>


More information about the QGIS-Developer mailing list