[Qgis-developer] Plugin management [was: QEP - Proposal for QGIS 3.0 after 2.14]

[Paolo Cavallini]

Il 24/10/2015 17:39, DelazJ ha scritto:
> I know you do that, Paolo. And I understand that it works with Tom
> plugin, right?

exactly

> - based on the description and the tags, make a list of mergeable
> plugins and let the dev know

this is reasonable, and a lot of work (we have >500 plugins now): glad
you are willing to help in compiling the list. feel free to start.

> - be more restrictive and reject new plugin that duplicates an already
> approved one, unless he proves that it's better than the existing, in
> which case he should have improved that one. I'm not a developer and I
> don't know how they resist to rules/obligations... but we need rules to
> expect consistency and coherence.

I am very cautious in rejecting someone's work. Our choice in QGIS has
always been to be inclusive, and this has proved hugely successful, when
compared to other projects.
I try to push gently, rather.

> - the duplication of plugins
> 
> - no real way to know/understand in which menu the installed plugin is
> (maybe, a reorganisation of menus should be done with 3.0)

this is partly possible (check the "category" tag, but I agree this
should be more predictable and easier to spot.

> - the bugs in the plugin, although QGIS project is not responsible of
> this (except globe?). People should clearly know that not all plugins
> are done by the QGIS project. This should be clearly added to the
> « Manage and Install plugins » dialog , meaning that :
> 
> * the plugins that are Core should be clearly identified ; currently I'm
> not sure they have real description and an author (I don't have QGIS
> right now to check so sorry if that exists) ;
> 
> * also emphasize the individual authors but also the way people can
> report issues. Instead of having on a single line links to homepage, bug
> tracker and code repository we can have 3 lines with text like «
> homepage:», « have issues or want new features, report it here : », « if
> you want to download sources :». When you are not a programmer, the
> latter expressions are more understandable than the former.
> 
> - the lack of documentation : Requesting from each plugin to have a
> minimal documentation. Things are not so obvious for all of us. So, as
> soon as there are options to choose from, there should be a text that
> explains the choice. It can just be a dialog that pops up in QGIS but
> there should be doc.Description is now mandatory and it's a good thing
> that helps to know if a plugin can be useful or no but doc is needed
> once you begin to try it.

I'm trying to gently push towards this as well. I have about 10 plugin
queueing because of lack of feedback from authors, and I feel sorry
about this, as users are missing potentially useful functions.

> - the language: I know we can't have all plugins translated in all
> languages but we may try to translate their description. Make
> translatable the plugins.org <http://plugins.org> site. I understood
> from Alesssandro that it will be a huge project [0] but I still think
> that it will be a huge improvement for QGIS. The translated descriptions
> will be retrieved in the « Manage and Install plugins » and according to
> the level of translations, users can have translated descriptions for
> all their plugins.

I'm not 100% sure having a translated description without a translated
plugin is very good for users. Feel free to open a ticket on this.
More importantly, remember that the whole plugin management is voluntary
work (except for some funding for specific improvements of the
infrastructure), so securing some funding is crucial to implement all
the above, and more.

All the best, and thanks for your thoughts.


-- 
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html