Review process on plugins.qgis.org and improvements

[Étienne Trimaille]

QGIS Enhancement: plugins.qgis.org review process and improvements

Date 2021/03/21

Author Etienne Trimaille (@Gustry)

Contact etrimaille at 3liz com

maintainer @Gustry

Version Not related to a QGIS version

Summary

There is more and more plugins being submitted on https://plugins.qgis.org
Despite the efforts from a few members, reviewing plugins is not easy as all new plugins and new versions (of an existing plugin) lands in the "unapproved" plugin list. This QEP is to add a proper system for reviewing plugins.

Proposed Solution

The "unapproved" list is mix of plugins which are :

• new plugins
• new versions of an existing plugin
• plugin which will never get approved, because
  • their work has been merged in another plugin
  • the plugin didn't meet the submission requirements
  • ...

Sometimes, on mailing list, there are emails from people asking what is the status of their submission.

A better reviewing workflow would make things easier, for both plugin developer and the reviewers.

For new plugins :

• The plugin lands in the "new unapproved" list
• If the reviewer let some comments on the bugtracker, the plugin goes into "pending review", so other reviewers will know that this specific plugin has already some comments on its bug tracker
• We keep the system for the "approved list"
• If a plugin in the "pending review" or "new unapproved" for too long, it goes into the "backlog list", a new version will put it back in the "new list"
• Reviewers and developer can have some editors comments to make the review easier ?

Affected Files

https://github.com/qgis/QGIS-Django

Further Considerations/Improvements

In the remaining time, some actions might be taken on the QGIS-Django repository :

• Update documentation about plugin approval, requirements, delay on the submission page
• Check the list of unapproved plugins which are there for a long time https://plugins.qgis.org/plugins/unapproved/ and make some triaging
• Bug triaging
• Not showing server plugins in QGIS Desktop if not necessary : qgis/QGIS#36284
• Having editor comments : qgis/QGIS-Django#42
• List of plugins having Processing enabled in their metadata

Votes

(required)

[Étienne Trimaille]

@NyakudyaA and @pcav comments are welcome about your review process

[mazano]

Yes, @Gustry I think if we could have the same workflow as one that is employed for the style hub where a user gets notified through email. A couple of things that come to mind with regards to approvals

• How to manage transfer/ownership of plugin where an author has now decided against maintaining the plugin.
• Plugin validity - If a user publishes a plugin with functions that are not available in core. Over time the functions become available in core. Do we keep the plugin published in the plugin repository?
• We need one central place to comment on the status of the plugin. Sometimes plugins sit in the queue for months because the author does not check his Github account. This generally also is a bad indicator that if this plugin has issues when approved the author will not respond in time. Some email addresses that are populated in metadata.txt do not work so we should resort to sending out emails using the address that they used to login to plugins.org
• A clear policy on managing plugins with binaries. Should we approve such plugins or not.
• If a plugin has already been approved, are new versions of the same plugin automatically updated. What situation can warranty a new version not to be approved

[Étienne Trimaille]

How to manage transfer/ownership of plugin where an author has now decided against maintaining the plugin.

We should use the issue tracker IMHO, no ? Whenever possible.

Plugin validity - If a user publishes a plugin with functions that are not available in core. Over time the functions become available in core. Do we keep the plugin published in the plugin repository?

Yes, like the ArrayPlus plugin. I guess when all function are in core, then the metadata.txt should updated with qgismaxversion. It's the easiest to do.

We need one central place to comment on the status of the plugin.

I think the reverse.

I think we should just a have a small flag saying "contact is taken with the author on the related issue tracker". So the approval team, can know without going to the github link then issue tracker than one of the team already made a first contact and first review of the plugin.

We should encourage them to check their issue tracker.
When the plugin will be approved, they will have potentially contributors, users creating issue, feature request ...

Maybe with a information box when the plugin is submitted.
Maybe send them an email from plugins.qgis.org about to check their issue tracker ?

A clear policy on managing plugins with binaries. Should we approve such plugins or not.

This should be raised on the qgis-dev ML I think. I didn't want to change the current workflow of approval without discussion upstream about this.

If a plugin has already been approved, are new versions of the same plugin automatically updated. What situation can warranty a new version not to be approved

Same as above.

[Tim Sutton]

We should probably replace the term 'pending review' with 'pending feedback' rather to make the status clearer.

[Anita Graser]

Hi @Gustry, have you already sent a final report for this funded enhancement? It would be great if you could add a link in qgis/PSC#56.