How to add your plugin to this repository

• You will need an OSGEO ID  to publish a plugin
• Go to QGIS plugin repo and click on Share a plugin.
• For a prompt approval of the plugin read the following guidelines

Requirements

• Plugins need to have at least minimal documentation
• The plugin metadata contains a valid link to the homepage, the repository (source code), the tracker (issue tracker) and a license
• The plugin license is compatible with the GPLv2 or later (more information about licensing)
• Respect the licenses by libraries and other resources that your plugin uses
• If the plugin has an external dependency, this needs to be clearly stated in the About metadata field; you can include a short guide to install Python libs as needed, or opint to existing guides, e.g. for Windows https://landscapearchaeology.org/2018/installing-python-packages-in-qgis-3-for-windows/
• Don't include binaries
• The size of the plugin package should not exceed 20MB

Recommendations 

• Write comments in your code in English, it will make it easier for others to contribute
• Provide a minimal data set for testing
• Put the plugin into the appropriate menu (Vector, Raster, Web, Database)
• Before publishing a new plugin, check if it duplicates existing functionality and explore collaboration possibilities
• Make your plugin work on all supported platforms (Windows, Linux, macOs)
• Don't rename the plugin title just because it's upgraded to a newer version like QGIS 3
• Check if source code uploaded to the QGIS plugin repo as zip is identical to "Code repository" indicated in metadata.txt
• Mention any requirements, dependencies and restrictions in the description text section (which can be multi-line). Examples of requirements, dependencies and restrictions are, if the plugin is running only on selected platforms, requires SW to be installed separately or some user account, but also if the plugin is spatially covering just some countries or regions.

Tips and Tricks 

• Keep your source repository in good shape:  
  • No generated files left in the repository (ui_*.py, resources_rc.py, gen. help files…).
  • No __MACOSX, .git, __pycache__ or other hidden directories
  • Good code organization (subfolders).
  • Code comments are available.
  • PEP8 & Python/QGIS guidelines compliance.
  • A README file and a LICENSE file are present.
• If some dependencies are not available in OSGeo4w Python, provide instructions on how to install them on Windows.
• The name of the plugin and the folder name do not repeat the word `plugin`.
• Plugins should make use of QgsNetworkAccessManager instead of using urllib2/requests/etc... which often fail to use correct proxy settings.
• The plugin builder plugin is recommended, especially for new users.

Plugin approval process

The approval of plugins is primarily carried out by contributors. Currently, the primary contributor is Admire Nyakudya ([email protected]). Do not hesitate to get in touch with him if you have any questions about the plugin approval process.

The approval process involves the following steps.

• New Plugins

All new plugins follow the rough guidelines outlined below:

• Plugin metadata.txt should be properly populated with working links i.e.:
  • Plugin home page - This link should direct users to a page on a website that describes the plugin functionality. If you do not have a dedicated page on your website that describes plugin usage, please use the README in the repository or use the code repository as the link. Any other links will result in the plugin being rejected.
  • Tracker - This should link to the issue tracker in your code repository.
  • Code repository - This should link to the code repository. It is expected that the code in the repository is accessible and not a zip file. The repository should also be publicly accessible. Plugins that utilize binaries will not be approved. If you feel that there is no way to provide your plugin without binaries, please reach out to the QGIS Developers mailing list to motivate your case or the QGIS PSC for further discussions.

Note: Plugins cover a whole range of domains which the person doing the approval might not be versed with. With such an expectation, we will try to do random tests (random plugins will be selected) to see if the plugin installs and runs without crashing QGIS. We also expect plugins to be cross-platform, working on Unix systems and Windows. In the list of published plugins, we have a diverse range of plugins offering different functionality. We encourage plugin developers to collaborate on plugins offering the same functionality as developing plugins with functionality that is almost similar. If you need to enhance a particular plugin, we are able to facilitate this with an existing author. For issues relating to the transfer of ownership, or updating any other metadata about existing plugins, please do not hesitate to contact us through the QGIS Developer mailing lists.

• Existing Plugins (New updates)

These are plugins that are already in use and being enhanced by new versions being uploaded. During the approval process, we expect the following:

• Properly update metadata to include a changelog. This will be beneficial for users to understand what has changed between versions.
• Properly annotate versions with new version numbers.
• We will also check the metadata.txt links i.e. plugin homepage, tracker, etc. to see if they are still working.

Note: Testing will also be done randomly to see if the plugin still works and does not crash QGIS.

We try to publish/approve plugins daily with the exception of weekends. If you have uploaded a plugin on Friday-Sunday, it will most likely be approved on Monday. During extended holiday periods, the timelines might be even longer. We also take into consideration that contributors live in different parts of the world with different public holidays. This might also impact the timelines for approval.