[QGIS-Developer] Reworking the QEP approach

[Nyall Dawson]

On Thu, 21 Nov 2024 at 20:07, Even Rouault <even.rouault at 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 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.
>