<div dir="ltr"><div>Hi Nyall,</div><div><br></div><div>Thank you for raising this topic, having worked with both GDAL and QGIS RFC/QEP systems, I agree that we can borrow the GDAL procedure, we just need to define the acceptance criteria (i.e. who can vote).</div><div></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 20, 2024 at 11:52 PM Nyall Dawson via QGIS-Developer <<a href="mailto:qgis-developer@lists.osgeo.org">qgis-developer@lists.osgeo.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hey all,<br>
<br>
This has been on my mind for a while -- I'd like to kick off<br>
discussions about how we can rework (fix?) the QEP approach to make it<br>
more useful for everyone.<br>
<br>
Right now we are just using GitHub issues for submission + comments on<br>
QEPs. But this leads to an awkward ambiguity at the conclusion of QEP<br>
discussion. Is a QEP ever really accepted? Does the end of discussion<br>
mean it's approved? When do we formally "kill" a QEP when the<br>
consensus is that it's not wanted?<br>
<br>
Right now everything just ends up in the same state -- an open ticket.<br>
Maybe someone will label it with "implemented", but we're inconsistent<br>
in doing that.<br>
<br>
It's REALLY hard to even just see what QEPs are locked in and which<br>
should form part of QGIS development practices. This is preventing<br>
them from being used for policy changes (eg<br>
<a href="https://github.com/qgis/QGIS-Enhancement-Proposals/issues/304" rel="noreferrer" target="_blank">https://github.com/qgis/QGIS-Enhancement-Proposals/issues/304</a> )<br>
<br>
In short, there's just a lot of ambiguity in the process.<br>
<br>
I think we could do better, and I'd suggest we follow GDAL's approach.<br>
This would require:<br>
<br>
1. Some formal policy for voting on QEPs, and corresponding criteria<br>
for acceptance / rejection.<br>
2. Reworking the QEP documentation so that we don't use issues for<br>
proposals, but rather use pull requests where the final proposal text<br>
becomes a markdown page in the repository.<br>
(3. anything else?)<br>
<br>
Thoughts?<br>
<br>
Nyall<br>
_______________________________________________<br>
QGIS-Developer mailing list<br>
<a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
</blockquote></div><div><br clear="all"></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Alessandro Pasotti</div><div>QCooperative:  <a href="https://www.qcooperative.net" target="_blank">www.qcooperative.net</a><br></div>ItOpen:   <a href="http://www.itopen.it" target="_blank">www.itopen.it</a></div></div>