Hi, I think we need improve the add-ons quality as far as possible, and our revision should cover code optimization if we can. However, I agree with you: add-ons can benefit a small number of user, but it's one of its potential case.
If we accept these guidelines:1. I will continue mantaining placeMarkers, readFeeds, clipContentsDesigner, and eMule emoticons and teamViewers if these three last add-ons require some changes. 2. I will continue reviewing code quality for SPL and dropbox, providing suggestions though i don't have enough time to review the full code each release. 3. As an add-on can benefit a few users, I suggest to continue PCBRL Keyboard with the feature which I started and abandoned, to provide access to write braille with a hand.
Thanks. El 30/01/2015 a las 0:58, James Teh escribió:
Hi all, This is a spin off from Joseph's proposal concerning Newfon, but the issue is much wider than that. This is something I've been meaning to post about for a while. At the moment, the bar for getting an add-on accepted and listed on addons.nvda-project.org is quite high. The great thing about this is that it ensures quality and that it can be used by users in as many languages as possible. The downside is that it is difficult for some useful add-ons to be submitted, which results in heavy usage of unofficial add-on repositories, opening users to illegal and potentially harmful add-ons. The reality is that some add-on authors don't care if their add-ons are super optimised, untranslated or unmaintained, and often, the majority of users don't care either. In fact, it simply doesn't make sense to translate some add-ons; e.g. an add-on for a piece of software which is itself monolingual. Sometimes, an add-on author might want to release an add-on to benefit the community but does not want to maintain it. Svox Pico, Festival and Newfon are good examples. NV Access and others don't want to maintain these, but they do benefit people, even unmaintained as they are. Furthermore, there is a burden on add-on maintainers to continue to release new versions of add-ons with new translations, etc. and sometimes even to fix bugs. This is often done without any help from the author and sometimes even after the author has long stopped caring about the add-on or disappeared. I feel this is an inefficient use of the maintainers' time and makes add-on maintenance a job that few will want or be able to do. While we do want to ensure some degree of quality (see below), the idea of the add-ons repository is to get useful stuff into the hands of users. An add-on doesn't have to serve everyone; it's good enough for it to serve a few. It's better that it serve some users rather than not being available to anyone or being obtained from questionable sources. NVDA itself is strictly quality controlled and users can rely on this, but I don't think this needs to be the case for the entire add-ons repository. Certainly, this is how add-on repositories for most other software work. So, here's a rough outline of how I think things could work: 1. When an add-on is submitted, it still needs to be reviewed. However, rather than reviewing for absolute code quality, the review should just cover major problems such as malicious code, unintentionally harmful code, major security hazzards, critical crashes, illegal activity, etc. Other suggestions can be made, but they shouldn't be requirements. 2. It shouldn't be required that every add-on is translatable or fully translated before it is released. However, if an add-on isn't translatable or fully translated, it should be clearly indicated to users that it will only work in specified languages. 3. Add-on authors should be responsible for making new releases of their add-ons, even if just to include new translations. Of course, translating can still be delegated to the translators, but it's up to the add-on authors to work with the translators and make their intentions clear. 4. If there are major problems of the kind noted above reported for an add-on by users without any intention from the add-on author to rectify them within a certain period (perhaps 3 months), the maintainers have the right to remove the add-on. This allows for a certain degree of trust without being overly burdensome. 5. Of course, these are just guidelines and the maintainers may choose to vary these in specific circumstances (following discussion) if they feel it is appropriate. For example, if an add-on is discovered to be very harmful, it might be best to remove the add-on immediately to avoid further harm to users. 6. It would be good to have ways to rate add-ons, feature popular or extremely high quality add-ons, etc. so users have some indication of popularity/quality. None of this is intended to devalue the hours of hard work that the add-on maintainers have done. Your efforts are very much appreciated and have not gone unnoticed. My only motiviation is to grow the add-on community and make less work for the maintainers. Thoughts appreciated. Thanks, Jamie
--- El software de antivirus Avast ha analizado este correo electrónico en busca de virus. http://www.avast.com ----------------------------------------------------------------NVDA add-ons: A list to discuss add-on code enhancements and for reporting bugs.
Community addons are available from: http://addons.nvda-project.org To send a message to the list: nvda-addons@xxxxxxxxxxxxx To change your list settings/unsubscribe: //www.freelists.org/list/nvda-addons To contact list moderators: nvda-addons-moderators@xxxxxxxxxxxxx
