On Thu, 21 Nov 2024 at 20:07, Even Rouault <even.roua...@spatialys.com> wrote: > > 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.
Agreed -- I think trying to assign areas of code is a mistake, and proved unworkable in the past. I'd also drop the "Project QEPs require majority PSC vote" policy, and instead leave project/PSC-level decisions completely out of the QEP system. They aren't being used for that anyway, PSC have their own approaches. Another change I think is necessary would be extending the "Must be open for at least one week" requirement to two weeks. Nyall > > 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@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. > _______________________________________________ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
