<div dir="auto">Hi,<div dir="auto"><br></div><div dir="auto">Unfortunately I was not able to attend the user conference in Switzerland this year, but I'm really curious about the results of the discussions with regards to this topic! What is the main conclusions and is there any paths forward with respect to trusted plugin maintainers or easen the burden to rewiev plugins?</div><div dir="auto"><br></div><div dir="auto">Best regards</div><div dir="auto">Axel</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">Den tors 1 okt. 2026 21:15Célia Buira via QGIS-Developer <<a href="mailto:qgis-developer@lists.osgeo.org">qgis-developer@lists.osgeo.org</a>> skrev:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A few more ideas to throw in:<br>
<br>
<br>
On the metadata:<br>
Adding more tags is a good idea to me, I would also consider the following tags<br>
* isLocal: Yes/No ?<br>
* If yes, what is the geographic scale : Supranational body/ national<br>
/ regional / city ?<br>
* Connect to the internet: Yes/No ?<br>
* Is a fork: Yes / No ? Of which plugin ?<br>
<br>
Periodically ping homepage/code repository url see if they are still<br>
valid and send a warning to plugin maintainer.<br>
<br>
<br>
On the plugin review/autocheck:<br>
Thanks a lot @Admire, for the hard work of reviewing plugins, it is a<br>
tricky position to be the one deciding the fate of the plugin, I think<br>
this burden should not rest on the shoulders of a single individual,<br>
and should instead be community shared.<br>
<br>
Blender does something like that, with an approval queue when anyone<br>
can comment with a few labels awaiting for review/ awaiting for change<br>
etc... before the final green light [1]<br>
<br>
To reduce the burden on reviewers and to remove one of my biggest<br>
frustrations which is when you install a plugin and it instantaneously<br>
crashes on install. We could introduce an autocheck with the QGIS<br>
docker image, and a script that mimic what QGIS is doing when it<br>
install a plugin, the code is already mostly in python and is located<br>
here : see `loadPlugin` and `startPlugin` in utils.py [2]<br>
<br>
I would do this check for the latest LTS and latest stable if the<br>
plugin supports it, and to be fair I would purge any plugins from the<br>
repository that doesn't comply with it today.<br>
<br>
I would also add a certain time threshold a plugin has to live<br>
*outside* of plugins.qgis before someone can submit it to the<br>
community repository.<br>
<br>
<br>
Finally a more economical/ socially fair reflexion :<br>
<br>
> the ease of publishing plugins is one of QGIS strengths. Anyone can push a plugin for his colleagues/friends<br>
<br>
It's probably what made the QGIS ecosystem what it is today, but it<br>
could also be what's killing it now that anyone can vibe code a plugin<br>
with a single prompt.<br>
<br>
Don't get me wrong, vibe coding a plugin to speedup your specific<br>
workflow is perfectly fine. but not at the expense of QGIS.org<br>
infrastructure. In this regard I would probably try to identify the<br>
free-rider commercial projects that outsource the cost of<br>
hosting/distributing a plugin without contributing back to QGIS.org.<br>
<br>
Looking forward to discuss this in Laax,<br>
<br>
Cheers,<br>
Célia<br>
<br>
[1] <a href="https://extensions.blender.org/approval-queue/?page=2" rel="noreferrer noreferrer" target="_blank">https://extensions.blender.org/approval-queue/?page=2</a><br>
[2] <a href="https://github.com/qgis/QGIS/blob/1407f8dbd6528108944e7a8dd2bead5cb7c35c13/python/utils.py#L437" rel="noreferrer noreferrer" target="_blank">https://github.com/qgis/QGIS/blob/1407f8dbd6528108944e7a8dd2bead5cb7c35c13/python/utils.py#L437</a><br>
<br>
<br>
Le jeu. 1 oct. 2026 à 19:15, Régis Haubourg via QGIS-Developer<br>
<<a href="mailto:qgis-developer@lists.osgeo.org" target="_blank" rel="noreferrer">qgis-developer@lists.osgeo.org</a>> a écrit :<br>
><br>
> Good, we have lots of ideas to process here.<br>
> Does someone would take the lead for a workshop during the contributor<br>
> meeting next week ?<br>
> The process is simple : just add a track at<br>
> <a href="https://github.com/qgis/QGIS/wiki/29th-Contributor-Meeting-in-Switzerland#thursday-sessions" rel="noreferrer noreferrer" target="_blank">https://github.com/qgis/QGIS/wiki/29th-Contributor-Meeting-in-Switzerland#thursday-sessions</a><br>
> and send a message to the list and our brand new Signal contributor channel<br>
><br>
><br>
> Best regards,<br>
><br>
> Régis Haubourg<br>
> Elected member at the Program Steering Comitee of QGIS.org.<br>
> -<br>
><br>
> On 30/09/2026 16:25, Nicolas Godet wrote:<br>
> > Hi Régis,<br>
> ><br>
> > Indeed, 2 categories were what I had in mind: official/trusted/approved/name_TBD and community (all other plugins).<br>
> ><br>
> > To be listed in the first one would require a large amount of downloads/stars, should work on current supported QGIS versions (to filter heavily downloaded old plugins which are not useful anymore but maintainers did not deprecate them), new plugins could apply on motivated candidature proving why they should be listed, automatic listing from trusted users…<br>
> > All above are raw ideas.<br>
> ><br>
> > New checkbox in plugin manager to enable community plugins with a clear warning that using these plugins is at your own risk.<br>
> ><br>
> > I do not know the current workflow for plugin approval, how many people have approving rights, the approval checklist, etc. I know some work has been done to document the process, but looking at Admire’s answer in a separate thread, approval rules need some polishing and hardening to avoid the loss of trust in the QGIS plugin repository.<br>
> ><br>
> > Kind regards,<br>
> > Nicolas<br>
> ><br>
> >> Le 30 sept. 2026 à 13:59, Régis Haubourg via QGIS-Developer <<a href="mailto:qgis-developer@lists.osgeo.org" target="_blank" rel="noreferrer">qgis-developer@lists.osgeo.org</a>> a écrit :<br>
> >> Hi, I agree that our community repository is really large now and the world has changed. What should be the direction we should take according to you? Something like an official repo, with a real security triage, and a filter of really up to date and active tools?<br>
> >> And besides this, community repositories, not activated by default ? Thanks for your ideas, user conference and community meeting is next week and a dedicated session would be wonderful<br>
> >> Cheers<br>
> >> Régis<br>
> >><br>
> >><br>
> >> On 30/09/2026 13:31, Nicolas Godet via QGIS-Developer <<a href="mailto:qgis-developer@lists.osgeo.org" target="_blank" rel="noreferrer">qgis-developer@lists.osgeo.org</a>> wrote:<br>
> >>> Dear all,<br>
> >>> I can’t agree more on the fact that the plugin repo has become a wild jungle with less and less interest in digging into it to find an innovative one.<br>
> >>> A few years ago, I spent a few minutes each week looking at each new plugin (because there were only ten or so). Now, I don’t look at new plugins anymore because there are too many of them and most of them are a duplicate of another plugin or, even worse, of a core feature.<br>
> >>> I think new rules should be put in place or at least a way to distinguish good, community-approved plugins from the nonsense garbage in the quest for likes for their LinkedIn post.<br>
> >>> Kind regards,<br>
> >>> Nicolas<br>
> >>>> Le 29 sept. 2026 à 17:45, Stefano Campus via QGIS-Developer <qgis- > <a href="mailto:developer@lists.osgeo.org" target="_blank" rel="noreferrer">developer@lists.osgeo.org</a>> a écrit :<br>
> >>>> <br>
> >>>> Good morning,<br>
> >>>> a few days ago, a plugin [1] was released that is a fork of an > existing plugin which had been updated (without the original plugin > author being notified) to QGIS 4.<br>
> >>>> The GitHub repository has issues disabled, so it is not possible to > report bugs that are present.<br>
> >>>> But shouldn’t it be mandatory to have issue reporting enabled?<br>
> >>>> Furthermore, the proliferation of plugins makes it difficult to find > the truly innovative ones.<br>
> >>>> So we see plugins that replicate core functions, perhaps giving them a > more appealing user interface<br>
> >>>> Where can I report this to the team that coordinates the plugins?<br>
> >>>> Do you think we should report these anomalies?<br>
> >>>> Many thanks<br>
> >>>> stefano<br>
> >>>> [1] <a href="https://github.com/veogeo/go3streetview" rel="noreferrer noreferrer" target="_blank">https://github.com/veogeo/go3streetview</a> <<a href="https://github.com/" rel="noreferrer noreferrer" target="_blank">https://github.com/</a> > veogeo/go3streetview><br>
> >>>> _______________________________________________<br>
> >>>> QGIS-Developer mailing list<br>
> >>>> <a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank" rel="noreferrer">QGIS-Developer@lists.osgeo.org</a><br>
> >>>> List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer 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 noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
> >>> _______________________________________________<br>
> >>> QGIS-Developer mailing list<br>
> >>> <a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank" rel="noreferrer">QGIS-Developer@lists.osgeo.org</a><br>
> >>> List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer 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 noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
> >> _______________________________________________<br>
> >> QGIS-Developer mailing list<br>
> >> <a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank" rel="noreferrer">QGIS-Developer@lists.osgeo.org</a><br>
> >> List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer 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 noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
> _______________________________________________<br>
> QGIS-Developer mailing list<br>
> <a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank" rel="noreferrer">QGIS-Developer@lists.osgeo.org</a><br>
> List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer 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 noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
_______________________________________________<br>
QGIS-Developer mailing list<br>
<a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank" rel="noreferrer">QGIS-Developer@lists.osgeo.org</a><br>
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer 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 noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
</blockquote></div>