[QGIS-Developer] Reworking the QEP approach

[Nyall Dawson]

On Thu, 21 Nov 2024 at 19:16, Régis Haubourg <regis.haubourg at gmail.com>
wrote:
>
> Hello,
> thanks for raising the issue, I share your analyze.
>
> Inspired by Kaban tooling to visually understand the flow and the current
state, I would just vote to use the "Project" tab in Github to view QEP in
columns. This will help in having labels maintained correctly. We can have
one project per Grant session for instance.
> Would that work for you ?

I'm not very familiar with Github Projects, but does that allow for
managing PRs (as opposed to just issue reports)? I REALLY want to move away
from issues.

> Using pull requests was what Nathan used at start but it turned out to be
really hard to maintain, so he switched back to issues.

I understand there were difficulties at the time, but it was nearly a
decade ago now and I'd like to try again 😄. As mentioned earlier, I just
don't think issues are working well from the perspective of being able to
easily see what proposals are accepted and formalised, which are rejected,
and which are pending comments. With PRs and one-per-page QEP (the GDAL
approach) we'd easily be able to see this:

- A page is created only when the QEP is approved (ie the PR is merged).
All the pages in the repo are just approved, locked-in proposals.
- The PR is closed when a QEP is rejected
- The open PRs are just those currently being discussed

Again, I think that GDAL's approach is working well - it's really easy to
see policies which are part of GDAL without having to trawl through a bunch
of tickets + comments, and you can easily see these even if you are new to
GDAL development.

Nyall


> We mix to levels of voting, the first one is the peer validation, the
second one is the vote for grant fundings, only restricted to a subset of
QEP's.
> I would indeed write down a formal process in the documentation, with a
link in QEP's issue template. Asking for a systematic announcement on the
mailing list to declare a QEP sounds good to me. It is easy to miss the
creation of an issue in a github repository.
>
> Régis
>
>
> Le mer. 20 nov. 2024 à 23:52, Nyall Dawson via QGIS-Developer <
qgis-developer at lists.osgeo.org> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20241122/1c1fc41c/attachment.htm>