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

[Julien Cabieces]

Hi, 

> On Wed, 28 Feb 2024 at 08:49, Marco Bernasocchi <marco at qgis.org> wrote:
>
>  Thanks Nyall, thanks Sandro,
>
>  Just a quick question, is the 
>   -is:draft 
>  Filter an option at all? I guess it does not reduce the n/r by default but could help?
>
>  https://github.com/qgis/QGIS/pulls?q=is%3Apr+is%3Aopen+-is%3Adraft
>
> That hides them, yes. But the bigger question remains as to what value having unfinished work in the queue has in the first place. In my opinion
> if it's not ready for review and merge, it's not actually a "pull REQUEST" and just doesn't belong there. In my proposal there's already mention
> that short term pull requests can be permitted for the express purpose of performing a CI test run, so after that why is there a need to allow
> unfinished work to remain in the queue? 
>
> If the need is for others to see and be exposed to unfinished work, then let's look at an extreme example: I have some 100's of branches of
> work in an unfinished state on my QGIS fork, from proof of concept experiments through to things which I just don't think work well enough to
> be submitted. Should all of those draft/wip branches be pull requests in the QGIS repo? 🤣 If the justification for allowing draft/wip requests is
> that others can see what's being/been done, then I guess the same argument would apply to all of this.
>

I think draft/wip pull requests are not a way to advertise what you're
currently working on. They are usefull when you want to discuss something with the
community like design, ui/ux or a critical fix, and a QEP is overkill.

So, it should not happen very often.


> Nyall
>  
>  
>  Cheers Marco 
>
>  On Tue, 27 Feb 2024, 23:09 Sandro Santilli via QGIS-PSC, <qgis-psc at lists.osgeo.org> wrote:
>
>  Thanks Nyall for raising this thread!
>
>  On Mon, Feb 26, 2024 at 09:21:05AM +1000, Nyall Dawson wrote:
>
>  > 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.
>
>  I would add that allowing long-term PRs also serves the purpose of making
>  it easy for contributors to check the state of their work against CI as
>  running tests locally is so hard that I dubt anyone is doing that.
>
>  > Policy #2: https://github.com/qgis/QGIS/pull/56523
>
>  [...]
>
>  > 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.
>
>  I think this is a limitation of the software used to get the list
>  of pull requests needing focus, and should be threated as such.
>  If github makes it hard to filter on "PR state" we could use a label
>  to do that.
>
>  --strk;
>  _______________________________________________
>  QGIS-PSC mailing list
>  QGIS-PSC at lists.osgeo.org
>  https://lists.osgeo.org/mailman/listinfo/qgis-psc
>
> _______________________________________________
> QGIS-PSC mailing list
> QGIS-PSC at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/qgis-psc


-- 

Julien Cabieces
Senior Developer at Oslandia
julien.cabieces at oslandia.com