[QGIS-Developer] Are there any real mandatory rules for publishing a plugin?

Thu Oct 1 12:15:40 PDT 2026

A few more ideas to throw in:

On the metadata:
Adding more tags is a good idea to me, I would also consider the following tags
* isLocal: Yes/No ?
* If yes, what is the geographic scale : Supranational body/ national
/ regional / city ?
* Connect to the internet: Yes/No ?
* Is a fork: Yes / No ? Of which plugin ?

Periodically ping homepage/code repository url see if they are still
valid and send a warning to plugin maintainer.

On the plugin review/autocheck:
Thanks a lot @Admire, for the hard work of reviewing plugins, it is a
tricky position to be the one deciding the fate of the plugin, I think
this burden should not rest on the shoulders of a single individual,
and should instead be community shared.

Blender does something like that, with an approval queue when anyone
can comment with a few labels awaiting for review/ awaiting for change
etc... before the final green light [1]

To reduce the burden on reviewers and to remove one of my biggest
frustrations which is when you install a plugin and it instantaneously
crashes on install. We could introduce an autocheck with the QGIS
docker image, and a script that mimic what QGIS is doing when it
install a plugin, the code is already mostly in python and is located
here : see `loadPlugin` and `startPlugin` in utils.py [2]

I would do this check for the latest LTS and latest stable if the
plugin supports it, and to be fair I would purge any plugins from the
repository that doesn't comply with it today.

I would also add a certain time threshold a plugin has to live
*outside* of plugins.qgis before someone can submit it to the
community repository.

Finally a more economical/ socially fair reflexion :

> the ease of publishing plugins is one of QGIS strengths. Anyone can push a plugin for his colleagues/friends

It's probably what made the QGIS ecosystem what it is today, but it
could also be what's killing it now that anyone can vibe code a plugin
with a single prompt.

Don't get me wrong, vibe coding a plugin to speedup your specific
workflow is perfectly fine. but not at the expense of QGIS.org
infrastructure. In this regard I would probably try to identify the
free-rider commercial projects that outsource the cost of
hosting/distributing a plugin without contributing back to QGIS.org.

Looking forward to discuss this in Laax,

Cheers,
Célia

[1] https://extensions.blender.org/approval-queue/?page=2
[2] https://github.com/qgis/QGIS/blob/1407f8dbd6528108944e7a8dd2bead5cb7c35c13/python/utils.py#L437

Le jeu. 1 oct. 2026 à 19:15, Régis Haubourg via QGIS-Developer
<qgis-developer at lists.osgeo.org> a écrit :
>
> Good, we have lots of ideas to process here.
> Does someone would take the lead for a workshop during the contributor
> meeting next week ?
> The process is simple : just add a track at
> https://github.com/qgis/QGIS/wiki/29th-Contributor-Meeting-in-Switzerland#thursday-sessions
> and send a message to the list and our brand new Signal contributor channel
>
>
> Best regards,
>
> Régis Haubourg
> Elected member at the Program Steering Comitee of QGIS.org.
> -
>
> On 30/09/2026 16:25, Nicolas Godet wrote:
> > Hi Régis,
> >
> > Indeed, 2 categories were what I had in mind: official/trusted/approved/name_TBD and community (all other plugins).
> >
> > 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…
> > All above are raw ideas.
> >
> > New checkbox in plugin manager to enable community plugins with a clear warning that using these plugins is at your own risk.
> >
> > 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.
> >
> > Kind regards,
> > Nicolas
> >
> >> Le 30 sept. 2026 à 13:59, Régis Haubourg via QGIS-Developer <qgis-developer at lists.osgeo.org> a écrit :
> >> 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?
> >> 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
> >> Cheers
> >> Régis
> >>
> >>
> >> On 30/09/2026 13:31, Nicolas Godet via QGIS-Developer <qgis-developer at lists.osgeo.org> wrote:
> >>> Dear all,
> >>> 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.
> >>> 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.
> >>> 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.
> >>> Kind regards,
> >>> Nicolas
> >>>> Le 29 sept. 2026 à 17:45, Stefano Campus via QGIS-Developer <qgis- > developer at lists.osgeo.org> a écrit :
> >>>> 
> >>>> Good morning,
> >>>> 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.
> >>>> The GitHub repository has issues disabled, so it is not possible to > report bugs that are present.
> >>>> But shouldn’t it be mandatory to have issue reporting enabled?
> >>>> Furthermore, the proliferation of plugins makes it difficult to find > the truly innovative ones.
> >>>> So we see plugins that replicate core functions, perhaps giving them a > more appealing user interface
> >>>> Where can I report this to the team that coordinates the plugins?
> >>>> Do you think we should report these anomalies?
> >>>> Many thanks
> >>>> stefano
> >>>> [1] https://github.com/veogeo/go3streetview <https://github.com/ > veogeo/go3streetview>
> >>>> _______________________________________________
> >>>> 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
> >>> _______________________________________________
> >>> 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
> >> _______________________________________________
> >> 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
> _______________________________________________
> 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