My two cents...I understand the validation requirements. But I think the fundamental problem is those plugin authors who submit a plugin for X and then describe it thusly: "This is a plugin for X" where X is the same name as the plugin. The problem is that this one word or very brief phrase isn't very clear. X may be called Y in another field. There may be several methods to do X (or Y) so the user doesn't really know what's being computed and how. X may do something in one field but may also be an undiscovered solution to a problem in another field so just saying "This is a plugin for X" just doesn't say much useful stuff.
Even a minimum word (readable) requirement for a plugin description would help! Frank > On Feb 23, 2015, at 8:49 AM, Alessandro Pasotti <[email protected]> wrote: > > 2015-02-23 15:41 GMT+01:00 Trevor Wiens <[email protected]>: >> In my experience Paulo has been doing good job of encouraging developers to >> do just that. >> >> If we want to formalize it further it might be a good idea to set the >> requirements lower for experimental plugins as it happens to be a helpful >> means of facilitating testing plugins on different platforms. > > Hi, > > speaking as the Plugin's repository developer, I would say that > implementing different validation rules for experimental/stable > plugins would require some not trivial refactoring. > > But if is there anybody out there willing to help, why not? > > The code is here: > https://github.com/qgis/QGIS-Django/tree/master/qgis-app/plugins > > and the validator: > https://github.com/qgis/QGIS-Django/blob/master/qgis-app/plugins/validator.py#L19 > > > > -- > Alessandro Pasotti > w3: www.itopen.it > _______________________________________________ > Qgis-user mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/qgis-user _______________________________________________ Qgis-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-user
