NVDA Community Addons/ NVDA add-on development and review processes

NVDA add-on development and review processes

Thank you for your interest in developing and submitting your NVDA add-on for community distribution. Since 2013, the NVDA community add-ons website is home to many add-on packages from authors like you.

The goal of this document is to serve as a one-stop guide on how the community review works, expectations, and to provide tips on effective add-on development and reviews. For more information on add-on development, please read NVDA Add-on Development Guide.

IMPORTANT: by submitting your add-on for community distribution, you acknowledge that you will abide by NVDA community code of conduct.

The overall add-on development and review processes is as follows:

Prepare

To develop an NVDA add-on, you will need a copy of NVDA. Although stable versions will work, we recommend using beta releases, or if you are really adventurous, alpha versions.

You will also need to install Python 3.7 or later for testing your add-on idea, and if using NVDA community add-on template, to package your add-on. Also, you will need access to the app you are writing an app module for, and software and hardware necessary for developing synthesizers or braille display driver add-ons.

Lastly, subscribe to NVDA add-ons mailing list to become familiar with the add-ons community. The forum is designed to help you develop your add-on by letting users give you feedback. It is also used to facilitate add-on reviews and new version announcements.

For other guidance, see guidelines.

Getting an add-on reviewed

If you would like to release your add-on to the NVDA community through community add-ons website, it must go through at least one review. First, have a public link to the development version of your add-on handy, such as the link to the installer, a version control repository such as GitHub, and so on. This is so that the prospective reviewer can download and test your add-on.

Once you have the download link handy, send a message to NVDA add-ons list requesting an add-on review. You must include the name of your add-on and a brief description as to what it does. Don't forget to include the public link to your add-on.

Once a review request is received, a prospective reviewer (not the author of the add-on in question) will review your add-on on the following criteria:

  • License and copyright: your add-on must be licensed in a way that is compatible with GNU General public license (GPL) 2 or later. This is a must because NVDA is licensed under GNU GPL version 2. To ensure this, at the top of add-on files, include a short copyright header, and if you are unsure, do ask the community for advice.
  • User experience: your add-on will be used by many people, so it will be subject to user experience tests such as installation, NVDA compatibility, GUI, and so on.
  • Documentation: users will learn a lot about your add-on with add-on documentation. Please make the documentation understandable to users.
  • Security: because your add-on becomes part of NVDA when activated, it can perform operations such as adding and removing files, accessing the internet, and read and write Windows Registry keys. The NVDA add-ons community takes security of add-ons seriously.

In the course of a basic review, a reviewer can approve the add-on for distribution or suggest changes. Often reviews are accompanied by comments dealing with user experience and other matters, so take a moment to review these comments. Once the add-on is approved, it will be queued for distribution on the community add-ons website.

IMPORTANT: even though the add-on passes other review criteria, if the license is not compatible with GPL 2, the add-on will not be approved.

In-depth reviews

In addition to the basic review (license and copyright, user experience, documentation, security), you can ask the add-ons community for in-depth reviews. In-depth reviews can include advanced audits such as memory leaks, compatibility with NVDA development snapshots, GUI suggestions, coding style, runtime conflicts with other add-ons, and flagging compatibility issues for different versions of Python. The add-on must first pass the basic review before in-depth reviews can be requested.

Combining with other add-ons

If it is determined that the add-on under review is similar to another add-on, the community may ask the author(s) to combine add-ons. In order to do so, community members must point out similarities and differences between candidate add-ons. If add-on author(s) agree that add-ons can be combined, this fact must be recorded in a subsequent add-on release for the combined add-on.

Maintenance

Now that your add-on was reviewed and approved, it is time to maintain the add-on. As you maintain the add-on, you will get feedback from users and other add-on authors. Do comment on their feedback and keep the communication going.

If you are using version control, you may wish to work with multiple branches to work on features or to synchronize with translations workflow. The "master" branch should be considered a development branch, suitable for testing add-ons before release. If using translations workflow, "stable" branch is used to exchange localization content and to release the add-on.

In case you are no longer able to maintain the add-on, send a message to NVDA add-ons list asking for a new maintainer. Any member of the community can then volunteer to maintain the add-on. The new maintainer becomes the author of the add-on, subject to rules set in this document.

Releasing a new version of an add-on

From time to time you will release updated add-on versions to add new features or fix bugs. In some cases you will release an add-on to make it compatible with newer NVDA releases.

When you are ready to release a new version or shortly after doing so, send a message to NVDA add-ons list, informing people of new releases. Provide the new version and a description of what was changed since the last release.

If you feel you would like a review from community reviewers, do let people know. This is applicable if you need to make changes regarding license.

Add-on removal

If harmful code is discovered while an add-on is listed on community add-ons website, it will be subject to removal. Harmful code can include downloading files without permission, adding, renaming, or removing files outside of add-on scope without permission, executing external programs outside of add-on scope, and compromising NVDA's functionality with malicious intent. A special case is inclusion of code that is not compatible with GPL or parts of proprietary licensed code without permission from the code author.

If harmful code is suspected or actually found, a member of the community must inform NVDA add-ons list of this issue. The reporter must provide the add-on name, version, author, and specific harmful code. If the community investigation determines that harmful code was indeed found, the author of the add-on must be contacted. The author must respond to community findings and take action such as replacing the harmful code, re-licensing it (subject to basic review again), or asking the community to remove the add-on from add-ons website. If the author does not take follow-up action, the add-on in question will be removed from community add-ons website.

Legacy status

Sometimes an add-on can be flagged as a legacy add-on. This can happen if the add-on becomes incompatible with most recent backwards incompatible version of NVDA (for example, 2019.3). This can also happen if features from the add-on becomes part of NVDA (Screen Curtain, for example) or is transferred to another add-on.

If an add-on should be declared as a legacy add-on, the add-on author or a community member must inform the NVDA add-ons list, preferably by the author. The reporter must provide add-on name, version, and reasons for flagging it as a legacy add-on such as features incorporated into NVDA. With an a greement from the add-on author and the community, the add-on in question will become a legacy add-on.

The opposite can happen where a legacy add-on is no longer flagged as such. The same procedure as flagging an add-on as a legacy add-on should be followed, except telling the community reasons for removing the add-on from legacy status. The add-on will be removed from legacy status if the author and the community determines that the add-on is no longer a legacy add-on. Maintenance priority goes to the author of the newly changed add-on, or a member of the community can volunteer to maintain the add-on.