[QGIS-Developer] Maintainance of QGIS Plugin repository

[Greg Troxel]

Admire Nyakudya via QGIS-Developer <qgis-developer at lists.osgeo.org>
writes:

> Over the years there has been a steady increase in plugins that are
> not approved <https://plugins.qgis.org/plugins/unapproved/>. This is
> due to a number of reasons:

> * Duplication of functionality. Plugin functionality already exists in QGIS.
>
I think it's good to reject plugins.  To the extent that there are fewer
while still being able to do things, it makes the user's job easier.
That's an argument about rules like duplication.

> * Plugin authors not willing to address issues raised during the
>   approval process.

I think the review committee should have high standards about
cooperation and it's ok to just close requests.

> * Plugins containing binaries (Not really sure about the policy here).

I haven't read it, but I think the rule should be  that plugsin
  - have a license which is compatible with qgis's license (they are
    derived works after all)
  - have a public repository and bug tracker

I also think that because qgis is broadly portable, a plugin needs to
have a story about how it's going to work on any computer which can run
qgi and run plugins.  that pretty quickly lands you at "no binaries",
but does admit "needs to build foo library".  For context, I use qgis on
NetBSD, and the modern world is dreadful at both "have this binary wheel
- it runs on 3 operating systems, 2 cpus each" and "to use this run
docker because our build system and instructions are such a mess that we
don't think you can build it".

Obviously (to me) proprietary binaries are totally out of the question.

> * Plugins which are a fork of an existing plugin and then they get
>   renamed to something else without permission from the original
>   author or the author is no longer interested i.e
>   https://plugins.qgis.org/plugins/active_fire2/.

Not clear why this is a hard no.  Could be failed as noise, could be
failed as failing to comply with community norms.  But if the original
is no longer maintained, and its a continuation fork, then it seems best
to unpublish the original and publish the fork.

> * Old plugins that still use the old architecture i.e Python2.

sure, that's a technical fail.

> Could we either implement the following changes to maintain/cleanup
> the plugin repository.
>
> * Old plugins that were never approved because the author did not care
>   to resolve issues flagged be deleted from the repository i.e
>   https://plugins.qgis.org/plugins/ban_adresse_locator/
>
> * Plugins that have vague names and offer functionality that is
>   ambiguious i.e https://plugins.qgis.org/plugins/upload/ be deleted.
>
> * We could automate the deletion of plugins where feedback has been
>   received but the author hasn't done any corrective measure maybe
>   after a month or couple of months.
>
> * Automatically flag the plugins which are not approved to Deprecated
>   after some time.
>
> I think the above and other recommendations will encourage people to
> use the plugin repository properly as currently it feels like a
> dumping ground.

I'm unclear on how the repository works, but it seems like it should be
a curated list of things that are ok and that involves kicking things out.

> On a side note: What is the policy for plugin names. I know it is up
> to the author to give his plugin a suitable name but something like
> https://plugins.qgis.org/plugins/transfer_layerfilegdb_to_geopackage/#plugin-versions
> looks like a description rather than a name.

agreed.


All in all, I think the repository approval team should be empowered to
be heavy handed, with appeal to PSC.