[QGIS-Developer] Reworking the QEP approach

Even Rouault even.rouault at spatialys.com
Thu Nov 21 02:07:19 PST 2024


Hi,

I'm very much for such a cleanup. For reference or inspiration, recently 
I captured the GDAL RFC process in 
https://gdal.org/en/latest/development/rfc_process.html

GDAL voting criteria are quite loose: at least +1 from 2 PSC members, no 
veto from a PSC member.

I see there are existing voting rules for QGIS QEPs documented in 
https://github.com/qgis/QGIS-Enhancement-Proposals?tab=readme-ov-file#process. 
They look reasonable to me, except that the rule about "+1 from 
maintainer of that area of code" is probably a bit difficult to enforce, 
if we don't have an official list of what are the components and their 
official maintainer, and how to keep it up-to-date when people silently 
walk away from the project.

Even

Le 20/11/2024 à 23:51, Nyall Dawson via QGIS-Developer a écrit :
> Hey all,
>
> This has been on my mind for a while -- I'd like to kick off
> discussions about how we can rework (fix?) the QEP approach to make it
> more useful for everyone.
>
> Right now we are just using GitHub issues for submission + comments on
> QEPs. But this leads to an awkward ambiguity at the conclusion of QEP
> discussion. Is a QEP ever really accepted? Does the end of discussion
> mean it's approved? When do we formally "kill" a QEP when the
> consensus is that it's not wanted?
>
> Right now everything just ends up in the same state -- an open ticket.
> Maybe someone will label it with "implemented", but we're inconsistent
> in doing that.
>
> It's REALLY hard to even just see what QEPs are locked in and which
> should form part of QGIS development practices. This is preventing
> them from being used for policy changes (eg
> https://github.com/qgis/QGIS-Enhancement-Proposals/issues/304 )
>
> In short, there's just a lot of ambiguity in the process.
>
> I think we could do better, and I'd suggest we follow GDAL's approach.
> This would require:
>
> 1. Some formal policy for voting on QEPs, and corresponding criteria
> for acceptance / rejection.
> 2. Reworking the QEP documentation so that we don't use issues for
> proposals, but rather use pull requests where the final proposal text
> becomes a markdown page in the repository.
> (3. anything else?)
>
> Thoughts?
>
> Nyall
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

-- 
http://www.spatialys.com
My software is free, but my time generally not.
Butcher of all kinds of standards, open or closed formats. At the end, this is just about bytes.



More information about the QGIS-Developer mailing list