[Qgis-community-team] Fwd: Re: A plea for plugin authors

[Paolo Cavallini]

Hi all.
I think this is a good suggestion. If someone points me to the
appropriate page to add these suggestions, I can do this.
I think this can improve significantly the publication and approval
process, and the overall quality of plugins.
All the best.

-------- Messaggio Inoltrato --------

It would be great if these guidelines could make it into the PyQGIS
Cookbook. It would be even better if the Cookbook could contain a bit
more on best practices for setting up a whole plugin project including
the repository and documentation. ...something like this blog post
<http://www.jeffknupp.com/blog/2013/08/16/open-sourcing-a-python-project-the-right-way/>
but specifically aimed at QGIS plugins.

On Wed, Mar 25, 2015 at 9:27 PM, Paolo Cavallini <cavallini at faunalia.it
<mailto:cavallini at faunalia.it>> wrote:

    Hi all.
    I would like to ask our plugin authors to take special care and
    attention to the following:

    Metadata
    ========

    * avoid using a name too similar to existing plugins
    * if your plugin has a similar functionality to an existing plugin,
    please explain the differences in the About field, so the user will know
    which one to use without the need to install and test it
    * avoid repeating "plugin" in the name of the plugin itself
    * use the description field in metadata for a 1 line description, the
    About field for more detailed instructions
    * include a code repository, a bug tracker, and a home page; this will
    greatly enhance the possibility of collaboration, and can be done very
    easily with one of the available web infrastructures (GitHub, GitLab,
    Bitbucket, etc.)
    * choose tags with care: avoid the uninformative ones (e.g. vector) and
    prefer the ones already used by others (see [1])
    * add a proper icon, do not leave the default one; see QGIS interface
    for a suggestion of the style to be used

    Code and help
    =============

    * do not include generated file (ui_*.py, resources_rc.py, generated
    help files…) and useless stuff (e.g. .gitignore) in repository
    * add the plugin to the appropriate menu (Vector, Raster, Web, Database)
    * when appropriate (plugins performing analyses), consider adding the
    plugin as a subplugin of Processing framework: this will allow users to
    run it in batch, to integrate it in more complex workflows, and will
    free you from the burden of designing an interface; a good example of
    this move is LecoS[0]
    * has at least minimal documentation and, if useful for testing and
    understanding, sample data.

    Further info at [2].

    Please write if you need further help.
    All the best.

    [0]

https://conservationecology.wordpress.com/qgis-plugins-and-scripts/lecos-land-cover-statistics/
    [1] http://plugins.qgis.org/plugins/
    [2] http://plugins.qgis.org/
    --
    Paolo Cavallini - www.faunalia.eu <http://www.faunalia.eu>
    QGIS & PostGIS courses: http://www.faunalia.eu/training.html