[Qgis-developer] one email address for plugin approvers

[Alex Mandel]

On 02/13/2014 03:15 AM, Richard Duivenvoorde wrote:
> On 13-02-14 10:35, Paolo Cavallini wrote:
>> Il 12/02/2014 13:38, Olivier Dalang ha scritto:
>>>     Multiline descriptions in the metadata are allowed, newlines are not
>>>     converted to BR in the HTML though...
>>>
>>> Good to know ! Is it ok to use HTML then ? Does the same apply to the
>>> changelog ? ...
>>
>> BTW: could we set up a checklist for plugin approval? IMHO this would
>> greatly smooth out the process.
> 
> Ok. Let's decide now and here:
> 
> On
> http://www.qgis.org/en/docs/pyqgis_developer_cookbook/releasing.html
> put something as
> 
> (partly take from http://plugins.qgis.org/plugins/: "How to add your
> plugin to this repository"):
> 
> Approval:
> 
> 1) your plugin will not be public until it is approved by a set of
> community approvers
> 2) give approvers some time to do this (after 2 weeks just email to...)
> 3) to approve we check that (checklist):
> 
> - does NOT show the orange block with missing metadata anymore in the
> plugin details page
> - has a very descriptive 'description' in the metadata.txt (which is
> seen by users in Plugin manager and on pluging.qgis.org)
> - contains no malicious code (?? pointers on how to check for approvers??)
> - starts without python errors (aka has some basis error handling)
> - has at least minimal documentation how to use/test it (visible from
> within the plugin!?)
> - provides a minimal data set (or links to) for testing
> - has a proper license (???? which one? and info about that??)
> - supports english language
> - does not duplicate of existing functionality or plugin, unless there
> is a very good reason (plz provide this reason in the description or
> metadata)
> 
> For the first point (orange block) can we standardize on Github? Can we
> ask from the average plugin author to put his code on Github? Because
> then an author has both an issuetracker and either a README or a wiki.
> 

We have always stated that any issue tracker/code hosting is acceptable.
Including:

github, bitbucket, sourceforge, or hub.qgis.org

We encourage the use of hub.qgis.org for the issue tracker and at least
a clone of a git repo if it's hosted elsewhere.
1. So tickets can all be on hub.qgis where a qgis user is likely to go
anyways
2. So it's possible for the community to easily adopt abandoned plugins,
or combine additional developers from other plugins.

I disagree with the need for a standard as coders should have
flexibility in their choice. I do agree that they should have something
though, hence we offer hosting if they're looking for the simplest option.

Thanks,
Alex