1. A developer writes an add-on.
  2. Developer submits the add-on to the community.
  3. Community considers the possibility of accepting the add-on through basic review (licensing, copyright considerations, security implications, etc.).
  4. If requested by the author, perform more rigorous review.

    1. Check that the add-on contains interesting and/or useful features.
    2. Perhaps, it can be merged with an existing add-on, or included into the NVDA core?
  5. If community considers the add-on to be useful, if accepted the add-on is now in development status.

Release and Maintenance

  1. Author releases the add-on and incorporates comments from reviewers and users.
  2. Author requests reviews.

    1. For major releases: Before major version is released to check for license changes and other basic review.
    2. For continuous releases: At least once a year.
  3. Reviewers and testers check the add-on that doesn't contain harmful code, and authorize to post it on the add-ons website.

  4. Authors or reviewers (preferably authors) can release maintainance versions of the add-on to update translations, or fix critical issues, notifying add-on changes on add-ons mailing list.

Deletion and Legacy Status

  1. Authors and reviewers should remove add-ons that contain harmful code, or if they are incompatible, if NVDA implements their functionality for instance, notify this into the add-ons mailing list.
  2. If add-ons no longer in active development, or reported as incompatible with recent NVDA releases will be listed as "legacy".
  3. Add-ons can be reinstated if harmful code has been removed, or add-on is compatible with recent NVDA releases again.


  1. If an add-on author is also a community reviewer s/he can not be the community reviewer for his/her add-ons at the same time.
  2. Users can be considered reviewers when they provide significant feedback, such as reporting bugs, suggestions, etc.
  3. Code will be considered to be harmful if it changes, deletes, or copies system files, or any external files without a clear and useful purpose, produces internet connections without a justified reason, etc.
  4. Authors should discuss about circumstances of add-ons if their add-on is not clear for copyrights, and licensing (such as synthesizer's licensing).
  5. For add-ons, master branch is equivalent to NVDA alpha, i.e. considered for testing purposes. Stable branch is considered to have had some testing and should be relatively error free/ok to run on your system.
  6. Stable branch receives translation updates if the add-on is translatable.
  7. Authors and reviewers are strongly encouraged to follow our guidelines, to ensure the quality of community add-ons.
  8. If any add-on author can not continue their work since first request that author can be replaced by another maintainer in three months.