A statement from NV Access
Hi Mick, you requested we alert you in case something is broken on the system. I receive alerts from the server and mr up is failing, as well of tasks for add-ons such as noBeepsSpeechMode or clipContentsDesigner.toggle quoted messageShow quoted text
Also, if You want, feel free to remove my email address from these notifications since I don"t have access to the server to maintain this, unless you consider that it is helpful to keep my email address to inform you.
Enviado desde mi iPhone
El 6 abr 2020, a las 4:58, Michael Curran <email@example.com> escribió:
Hello add-ons community,
Over the past couple of weeks, there has been some worry about what is happening to the add-ons system, and whether there are plans for the future.
Firstly, I would like to assure everyone that NV access sees the add-on community as an extremely important part of the NVDA ecosystem, and we want to ensure that we have an infrastructure that supports the creation and promotion of high-quality, secure, relevant, localized add-ons.
As a bit of back story, many years ago when NV access was much smaller, some members of the community created the current NVDA translation system. A mixture of scripts, svn and the Assembler service, which we agreed could be hosted on our server. Perhaps at the same time or perhaps a bit later (I'm not sure), code for managing the add-ons website addons.nvda-project.org and support for translating add-ons was also bolted on to this translation system by members of the community. This system has obviously worked up to now as we have many add-ons listed and translated, and NVDA itself continues to be translated into many languages each release.
However, over the past year or more, problems have been increasing with this system. The most common problem has usually been one or more translators incorrectly changing their settings file, and or not correctly handling a merge conflict. Sadly sometimes when this has happened, this would cause problems not just for their translation, but sometimes for the system as a whole. Then there was the most recent example of a major break, which was due to the work to move nvdaaddons team from bitbucket to github. Although this work made sense and NV Access agreed with the move, a mistake with ssh keys caused major havoc with NVDA translations. In short, an incorrect change to the add-on infrastructure caused NVDA translation commits to fail and then the translations became majorly out of sync. I had to go and do a lot of manual work to correct this.
Related somewhat to this, NV Access is not the small organisation it was several years back. We handle a great deal of data, and users depend on our services more and more. As a responsible organisation, we take out forms of insurance to protect us against unforeseen disaster. However, to comply with these policies, we must ourselves ensure that our systems are secure, we have adequate disaster recovery plans, and that we take full responsibility for those who manage our server/s. Our insurance providers frown upon access to our servers by non NV Access people. And up to now, the add-on and translation systems have been maintained by community members outside of NV Access with some form of access to our server.
Finally, to finish explaining the current state of things, as the add-on and translation systems were designed by other members of the community, we are being honest when we say that NV Access probably does not fully understand the systems, and when something does break, it takes a lot of time to fix. Time we could be better spending on NVDA itself, and performing our many many other important obligations required to run a charitable corporation.
Providing the above description of things is not at all to suggest blame on any community members. In fact, NV Access itself admits that we have probably left this issue way too long, and we truly want to recognize the tireless work that community members have put into maintaining things. My aim was in stead to be completely transparent with everyone, so that all can understand this is a pretty huge problem to solve and coordinate.
NV Access will be having its annual internal strategy day in two weeks. At this meeting we will be discussing priorities for the coming year. I can assure everyone that finding solutions for the add-on and translation systems will come out as one of the top priorities.
Reef from NV Access and a couple of other community members have been working on a new add-on workflow. It is documented at: https://github.com/nvaccess/addon-store-submission
I would encourage people to read it and provide as much feedback as possible. I personally would like to see a bit more conversation around requirements for how the system will automatically package an add-on (E.g. a standard scons command to run to produce a predictably named nvda-addon file), and what the requirements for translating add-ons are.
I don't want to say too much more about the workflow and or timelines before the end of April. But, I do want to stress a couple more final things.
Two specific goals I have with this particular project ahead are:
1. disconnect the NVDA translation system from the add-ons system. These are two separate systems, and if one breaks, it should not take down the other. Further to this, each translation should be separate enough that a mistake by one language maintainer does not break things for other languages.
2. We should use existing mainstream tools, outside of NV Access's internal infrastructure where possible. Tweaking scripts by a community member on an NV Access server is simply no longer an option.
We also need to consider priorities within this project. Again, without going deep into detail yet, I do see things in the following order of importance:
1. The NVDA translation system. This affects the most amount of users across the world by far. We must ensure this system is sufficient in features and protected against breakage.
2. Reviewing and publishing of add-ons.
3. Translation of add-ons.
NV access is committed to finding and implementing a solution. But it is going to take time. There may also be periods of time at which it may be impossible to translate add-ons, publish add-ons, or perhaps submit translations for NVDA. We will obviously try to minimize this as much as possible. There will also very likely be changes to the way that translators or add-on developers submit their work. We want to plan these changes with the community, but we also must ensure that what ever we come up with is sustainable, secure and stable.
NV Access will have more to say on all of this toward the end of April.
For now at least, registration of translations for new add-ons is not possible until we come up with a new solution. Please however alert me to any major breaks in the current system and I will try to address them when I can.
Thanks for your support and contributions.