Topics

proposed addon workflow

Mesar Hameed
 

Dear authors/reviewers.

Thank you for holding off making new releases, and for not pushing any commits to the new organization repos.

I have written up my thoughts here:
https://github.com/nvdaaddons/nvdaaddons.github.io/wiki/AddonWorkflow

Please have a read, and let me know your thoughts.
Thank you.
Mesar

 

Hi,
In regards to development snapshot releases: some of us host add-ons on
other websites (I host development snapshots on my personal website).
In regards to version numbering: the trend these days is using date-based
releases e.g. 20.01, 2020.1, etc.
In regards to release interval: about a week or two should work for majority
of cases. There are times when an author may need to release an emergency
patch to correct an important issue - the best known scenario being a stable
version of an add-on that relied on NVDA alpha material, and now the alpha
build changed things in a way that made the add-on fail to load, potentially
affect those using NVDA beta releases.
In regards to who will release add-ons: although we do need to emphasize
that the community should take a greater responsibility as to releasing
add-ons, I think authors should also have a say on that, acknowledging that
authors are also responsible for the health of their add-ons.
I'm holding off on add-on releases for a little while so feedback on Mesar's
proposal can be gathered, unless Mesar gives folks green light to upload
releases to add-on files repository.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io>
On Behalf Of Mesar Hameed
Sent: Thursday, January 2, 2020 8:14 PM
To: nvda-addons@nvda-addons.groups.io
Subject: [nvda-addons] proposed addon workflow

Dear authors/reviewers.

Thank you for holding off making new releases, and for not pushing any
commits to the new organization repos.

I have written up my thoughts here:
https://github.com/nvdaaddons/nvdaaddons.github.io/wiki/AddonWorkflow

Please have a read, and let me know your thoughts.
Thank you.
Mesar

 

Hi,
As a follow-up: I'm deleting extraneous branches from NVDA Add-ons
organization fork for my add-ons.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io>
On Behalf Of Joseph Lee via Groups.Io
Sent: Thursday, January 2, 2020 8:39 PM
To: nvda-addons@nvda-addons.groups.io
Subject: Re: [nvda-addons] proposed addon workflow

Hi,
In regards to development snapshot releases: some of us host add-ons on
other websites (I host development snapshots on my personal website).
In regards to version numbering: the trend these days is using date-based
releases e.g. 20.01, 2020.1, etc.
In regards to release interval: about a week or two should work for majority
of cases. There are times when an author may need to release an emergency
patch to correct an important issue - the best known scenario being a stable
version of an add-on that relied on NVDA alpha material, and now the alpha
build changed things in a way that made the add-on fail to load, potentially
affect those using NVDA beta releases.
In regards to who will release add-ons: although we do need to emphasize
that the community should take a greater responsibility as to releasing
add-ons, I think authors should also have a say on that, acknowledging that
authors are also responsible for the health of their add-ons.
I'm holding off on add-on releases for a little while so feedback on Mesar's
proposal can be gathered, unless Mesar gives folks green light to upload
releases to add-on files repository.
Cheers,
Joseph

-----Original Message-----
From: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io>
On Behalf Of Mesar Hameed
Sent: Thursday, January 2, 2020 8:14 PM
To: nvda-addons@nvda-addons.groups.io
Subject: [nvda-addons] proposed addon workflow

Dear authors/reviewers.

Thank you for holding off making new releases, and for not pushing any
commits to the new organization repos.

I have written up my thoughts here:
https://github.com/nvdaaddons/nvdaaddons.github.io/wiki/AddonWorkflow

Please have a read, and let me know your thoughts.
Thank you.
Mesar

Noelia Ruiz
 

Hi, I will send my opinion on list now. For me the workflow is
reasonable, especially taking account the reasons expresed under the
considerations section, about security (if pull request require at
least a review and the process can be automated and releases can be
done in the org to differentiate community and personal releases, they
can be considered as a procedure which tries to be reliable and
publicly documented; also for the other two reason about share
learning and reducing workload for admins).
We know that not all add-ons are accepted and that authors may not
send them to community for several reasons, though hope more add-ons
can be sent here and more reviewers can be involved.
As Joseph pointed out in other message, sometimes add-ons are released
more frequently than every two weeks, the minimum space recommended in
add-on guidelines to be translated. Of course not all add-ons will
need to be translated, for example if they run in a program just
available in English. Anyway, a possible way of shorting this out
would be that, for continue releasing, authors use their personal
account and when they consider this should be reviewed and released
from community, and possibly, in case this could be done, posted
automatically to the community website, they request this making a pr
to the protected master branch in the organization, so reviewers can
see multiple changes.
We know that add-ons are posted in other repos and websites, and
tested or reviewed outside this community / add-ons list. But I think
this procedure can be adopted by us for the reasons mentioned in
considerations.
About things to be improved/fixed in the document:
1. In the label of the link to the make add-ons translatable document,
I wouldn't use the word here but the whole or abbreviated title.
2. In step 10: 10.
Issues, pull requests should go to the author, and to the authors
repo, not to the community fork. We can add. Here is a [table of
personal repos](https://github.com/nvdaaddons/nvdaaddons.github.io/wiki/repos).
Adding repos to the table could be also considered a task for support
reviewers.
3. I would add also as a task the deletion of add-ons, which may be
moved to the legacy section of the website when they become not useful
or don't work as expected, for example due to changes in NVDA's
development.
4. I would add a link to the guidelines. Now we have several documents
(review processes, translated on the website), guidelines and now this
workflow. My impression is that guidelines aren't always consulted and
this may be due to the different documents linked in different places.
I would suggestto replace the processes by this workflow.
5. A note could be added about priorities of reviewers if needed. For
instance, I would consider a great priority if something releases a
patch to fix a bug which makes an add-on stop working for instance if
an api requires it (such as if the api used by InstantTranslate
requires changes), or other patches to fix things about add-ons
considered stable. I think that if we have add-ons under development
and we make a patch, this can be considered lower priority.
6. We may discuss about labels on the website. For example I have
three kind of add-ons maintained by myself: stable, development, most
of the time identical to the stable version, just in certain
situations, for testing, different, and old, compatible with old
versions of NVDA. I use two links (download stable and dowload dev)
for the same version most of the time. This maybe confusing. Also,
they are add-ons just hosted under development add-ons, and recently a
legacy section was created to host add-ons not working with the latest
stable version of NVDA. I think we should discuss this to improve the
usability of the website.
Thanks


2020-01-03 5:14 GMT+01:00, Mesar Hameed <mesar.hameed@...>:

Dear authors/reviewers.

Thank you for holding off making new releases, and for not pushing any
commits to the new organization repos.

I have written up my thoughts here:
https://github.com/nvdaaddons/nvdaaddons.github.io/wiki/AddonWorkflow

Please have a read, and let me know your thoughts.
Thank you.
Mesar



Brian's Mail list account
 

I'd agree about the text in links, its no good us moaning about mainstream websites having a huge list of links with here in them if we don't follow the rule ourselves. grin.
Speaking as a user myself, I am up for any way to make the add on web site easier to use, such as making sure that the point about version compatibility is laboured almost to the point of monotony, since people often miss this important point.
Also on all the mail lists perhaps some links to documents mentioned in this thread would be a good idea. Its probably not worth doing a monthly autopost of just this info but certainly getting info to the masses, not just developers has a good side, so people can see who is doing things etc.
Brian

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users

----- Original Message -----
From: "Noelia Ruiz" <nrm1977@...>
To: <nvda-addons@nvda-addons.groups.io>
Sent: Friday, January 03, 2020 7:40 AM
Subject: Re: [nvda-addons] proposed addon workflow


Hi, I will send my opinion on list now. For me the workflow is
reasonable, especially taking account the reasons expresed under the
considerations section, about security (if pull request require at
least a review and the process can be automated and releases can be
done in the org to differentiate community and personal releases, they
can be considered as a procedure which tries to be reliable and
publicly documented; also for the other two reason about share
learning and reducing workload for admins).
We know that not all add-ons are accepted and that authors may not
send them to community for several reasons, though hope more add-ons
can be sent here and more reviewers can be involved.
As Joseph pointed out in other message, sometimes add-ons are released
more frequently than every two weeks, the minimum space recommended in
add-on guidelines to be translated. Of course not all add-ons will
need to be translated, for example if they run in a program just
available in English. Anyway, a possible way of shorting this out
would be that, for continue releasing, authors use their personal
account and when they consider this should be reviewed and released
from community, and possibly, in case this could be done, posted
automatically to the community website, they request this making a pr
to the protected master branch in the organization, so reviewers can
see multiple changes.
We know that add-ons are posted in other repos and websites, and
tested or reviewed outside this community / add-ons list. But I think
this procedure can be adopted by us for the reasons mentioned in
considerations.
About things to be improved/fixed in the document:
1. In the label of the link to the make add-ons translatable document,
I wouldn't use the word here but the whole or abbreviated title.
2. In step 10: 10.
Issues, pull requests should go to the author, and to the authors
repo, not to the community fork. We can add. Here is a [table of
personal repos](https://github.com/nvdaaddons/nvdaaddons.github.io/wiki/repos).
Adding repos to the table could be also considered a task for support
reviewers.
3. I would add also as a task the deletion of add-ons, which may be
moved to the legacy section of the website when they become not useful
or don't work as expected, for example due to changes in NVDA's
development.
4. I would add a link to the guidelines. Now we have several documents
(review processes, translated on the website), guidelines and now this
workflow. My impression is that guidelines aren't always consulted and
this may be due to the different documents linked in different places.
I would suggestto replace the processes by this workflow.
5. A note could be added about priorities of reviewers if needed. For
instance, I would consider a great priority if something releases a
patch to fix a bug which makes an add-on stop working for instance if
an api requires it (such as if the api used by InstantTranslate
requires changes), or other patches to fix things about add-ons
considered stable. I think that if we have add-ons under development
and we make a patch, this can be considered lower priority.
6. We may discuss about labels on the website. For example I have
three kind of add-ons maintained by myself: stable, development, most
of the time identical to the stable version, just in certain
situations, for testing, different, and old, compatible with old
versions of NVDA. I use two links (download stable and dowload dev)
for the same version most of the time. This maybe confusing. Also,
they are add-ons just hosted under development add-ons, and recently a
legacy section was created to host add-ons not working with the latest
stable version of NVDA. I think we should discuss this to improve the
usability of the website.
Thanks


2020-01-03 5:14 GMT+01:00, Mesar Hameed <mesar.hameed@...>:
Dear authors/reviewers.

Thank you for holding off making new releases, and for not pushing any
commits to the new organization repos.

I have written up my thoughts here:
https://github.com/nvdaaddons/nvdaaddons.github.io/wiki/AddonWorkflow

Please have a read, and let me know your thoughts.
Thank you.
Mesar



Noelia Ruiz
 

I agree about posting a link to this workflow if accepted, since this
is a list for reviewers (considering as such users too).
Other think that maybe discussed: previously we had a list for
commits, but unfortunately new add-ons couldn't be added, at least
easily, due to changes in Bitbucket. Should be a subgroup or something
be created for commits in the org, or at least with the feed or
releases? Thoughts are appreciated.
Cheers

2020-01-03 9:04 GMT+01:00, Brian's Mail list account via Groups.Io
<bglists=blueyonder.co.uk@groups.io>:

I'd agree about the text in links, its no good us moaning about mainstream
websites having a huge list of links with here in them if we don't follow
the rule ourselves. grin.
Speaking as a user myself, I am up for any way to make the add on web site

easier to use, such as making sure that the point about version
compatibility is laboured almost to the point of monotony, since people
often miss this important point.
Also on all the mail lists perhaps some links to documents mentioned in
this thread would be a good idea. Its probably not worth doing a monthly
autopost of just this info but certainly getting info to the masses, not
just developers has a good side, so people can see who is doing things etc.
Brian

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users
----- Original Message -----
From: "Noelia Ruiz" <nrm1977@...>
To: <nvda-addons@nvda-addons.groups.io>
Sent: Friday, January 03, 2020 7:40 AM
Subject: Re: [nvda-addons] proposed addon workflow


Hi, I will send my opinion on list now. For me the workflow is
reasonable, especially taking account the reasons expresed under the
considerations section, about security (if pull request require at
least a review and the process can be automated and releases can be
done in the org to differentiate community and personal releases, they
can be considered as a procedure which tries to be reliable and
publicly documented; also for the other two reason about share
learning and reducing workload for admins).
We know that not all add-ons are accepted and that authors may not
send them to community for several reasons, though hope more add-ons
can be sent here and more reviewers can be involved.
As Joseph pointed out in other message, sometimes add-ons are released
more frequently than every two weeks, the minimum space recommended in
add-on guidelines to be translated. Of course not all add-ons will
need to be translated, for example if they run in a program just
available in English. Anyway, a possible way of shorting this out
would be that, for continue releasing, authors use their personal
account and when they consider this should be reviewed and released
from community, and possibly, in case this could be done, posted
automatically to the community website, they request this making a pr
to the protected master branch in the organization, so reviewers can
see multiple changes.
We know that add-ons are posted in other repos and websites, and
tested or reviewed outside this community / add-ons list. But I think
this procedure can be adopted by us for the reasons mentioned in
considerations.
About things to be improved/fixed in the document:
1. In the label of the link to the make add-ons translatable document,
I wouldn't use the word here but the whole or abbreviated title.
2. In step 10: 10.
Issues, pull requests should go to the author, and to the authors
repo, not to the community fork. We can add. Here is a [table of
personal
repos](https://github.com/nvdaaddons/nvdaaddons.github.io/wiki/repos).
Adding repos to the table could be also considered a task for support
reviewers.
3. I would add also as a task the deletion of add-ons, which may be
moved to the legacy section of the website when they become not useful
or don't work as expected, for example due to changes in NVDA's
development.
4. I would add a link to the guidelines. Now we have several documents
(review processes, translated on the website), guidelines and now this
workflow. My impression is that guidelines aren't always consulted and
this may be due to the different documents linked in different places.
I would suggestto replace the processes by this workflow.
5. A note could be added about priorities of reviewers if needed. For
instance, I would consider a great priority if something releases a
patch to fix a bug which makes an add-on stop working for instance if
an api requires it (such as if the api used by InstantTranslate
requires changes), or other patches to fix things about add-ons
considered stable. I think that if we have add-ons under development
and we make a patch, this can be considered lower priority.
6. We may discuss about labels on the website. For example I have
three kind of add-ons maintained by myself: stable, development, most
of the time identical to the stable version, just in certain
situations, for testing, different, and old, compatible with old
versions of NVDA. I use two links (download stable and dowload dev)
for the same version most of the time. This maybe confusing. Also,
they are add-ons just hosted under development add-ons, and recently a
legacy section was created to host add-ons not working with the latest
stable version of NVDA. I think we should discuss this to improve the
usability of the website.
Thanks


2020-01-03 5:14 GMT+01:00, Mesar Hameed <mesar.hameed@...>:
Dear authors/reviewers.

Thank you for holding off making new releases, and for not pushing any
commits to the new organization repos.

I have written up my thoughts here:
https://github.com/nvdaaddons/nvdaaddons.github.io/wiki/AddonWorkflow

Please have a read, and let me know your thoughts.
Thank you.
Mesar







Luke Davis
 

Hi

 

unfortunately have some serious concerns with this proposal.

 

  1. “Supporting reviewers”, which I guess are different than civilian or regular reviewers, are part of the NVDA Add-on Team. However the NVDA Add-On Team--who is on it, how they divide responsibilities, etc., is not defined in the document. Given that the scope of their authority and responsibilities seems greatly increased by this proposal, in my opinion that needs to be elaborated upon.

(As a side note: stylistically, the definitions section should be a heading like the other sections.)

 

  1. You say the following:

 

“6. Assuming sufficient user interest for the addon to be available on the community website then the author requests that the addon is forked to the nvdaaddons organisation by a supporting reviewer.”

 

Okay. So obviously an author thinks there is interest, or he would not have written the add-on in the first place. Or he thinks that if he builds it, they may come down the road. I’m sure there are cases of add-ons that were written because somebody was helping himself by writing an add-on, and thought the community would benefit later by having access to it, and released it without an interest study first.

So other than I think this requirement creates a potential catch 22, I wonder who determines whether there is user interest?

Because so far in the process, the author has only published info about the add-on to the add-ons mailing list for code review and comments. This is not the best place to determine user interest, but you are laying an “it has to be interesting enough to the users to be worthy of being on the community site” requirement on all new add-ons.

 

I dislike the “gatekeepers of user interest” idea that seems to be creeping in here.

The whole point of add-ons, I thought, was to have the broader user community developing for the broader user community. This proposal puts new developers in the position of having to drum up supporters ahead of time to argue for why it’s valuable, before even uploading the first dev version of an add-on.

As I understand it, up until now, if an author wrote an add-on, and it passed reviews of various concrete measurables, it got put on the community site, and we let the users decide if it was interesting. Going forward, interest will be determined in some vague way, by either the Add-On Team or the members of the add-ons list (all very busy people, who are usually programmers of some sort, and thus might not be thought of as normal users), during the brief one-two week open comment period.

 

I don’t know the discussions behind this proposal, but presumably there is concern in some circles about clutter on the community site—useless add-ons that are not desirable, and so a process is being created to stop that from happening in the future?

If that is indeed a problem we need to solve, maybe we can look at other potential solutions first?

 

Luke

 

 

From: Mesar Hameed
Sent: Thursday, January 2, 2020 11:14 PM
To: nvda-addons@nvda-addons.groups.io
Subject: [nvda-addons] proposed addon workflow

 

Dear authors/reviewers.

 

Thank you for holding off making new releases, and for not pushing any commits to the new organization repos.

 

I have written up my thoughts here:

https://github.com/nvdaaddons/nvdaaddons.github.io/wiki/AddonWorkflow

 

Please have a read, and let me know your thoughts.

Thank you.

Mesar

 

 

 

Noelia Ruiz
 

I am free this morning and I want to reply about add-on interest. I
remember an add-on not uploaded to the website. It consisted on
reporting the NVDA's version or something like that, and I think that
a reviewer proposed not to accept it.
Of course add-ons used by a minority of people are of interest too.
But personally I have at least two or three add-ons, maybe four (I am
remembering while I am writing) not reviewed, just uploaded to the old
Bitbucket account. I have also others just on my GitHub account,
writen to learn or to satisfy certain personal needs in the past. Of
course community can decide to review them later, but I think that we
cannot accept every add-on that is created just if it is secure and
pass orther requirement. In the first place it should be reviewed, and
to be reviewed it must produce interest to someone. Of course I would
review an add-on writen for people with mobility issues or not for a
wide range of people.
About style, I agree with you. And about dividing things or who can be
part of the add-on team, I think this is no so easy, but I agree on
discussing it.
Though dividing task is difficult since not all members have always
the same availability.
Cheers

2020-01-03 9:46 GMT+01:00, Luke Davis <luke@...>:

Hi

unfortunately have some serious concerns with this proposal.

1. “Supporting reviewers”, which I guess are different than civilian or
regular reviewers, are part of the NVDA Add-on Team. However the NVDA Add-On
Team--who is on it, how they divide responsibilities, etc., is not defined
in the document. Given that the scope of their authority and
responsibilities seems greatly increased by this proposal, in my opinion
that needs to be elaborated upon.
(As a side note: stylistically, the definitions section should be a heading
like the other sections.)

2. You say the following:

“6. Assuming sufficient user interest for the addon to be available on the
community website then the author requests that the addon is forked to the
nvdaaddons organisation by a supporting reviewer.”

Okay. So obviously an author thinks there is interest, or he would not have
written the add-on in the first place. Or he thinks that if he builds it,
they may come down the road. I’m sure there are cases of add-ons that were
written because somebody was helping himself by writing an add-on, and
thought the community would benefit later by having access to it, and
released it without an interest study first.
So other than I think this requirement creates a potential catch 22, I
wonder who determines whether there is user interest?
Because so far in the process, the author has only published info about the
add-on to the add-ons mailing list for code review and comments. This is not
the best place to determine user interest, but you are laying an “it has to
be interesting enough to the users to be worthy of being on the community
site” requirement on all new add-ons.

I dislike the “gatekeepers of user interest” idea that seems to be creeping
in here.
The whole point of add-ons, I thought, was to have the broader user
community developing for the broader user community. This proposal puts new
developers in the position of having to drum up supporters ahead of time to
argue for why it’s valuable, before even uploading the first dev version of
an add-on.
As I understand it, up until now, if an author wrote an add-on, and it
passed reviews of various concrete measurables, it got put on the community
site, and we let the users decide if it was interesting. Going forward,
interest will be determined in some vague way, by either the Add-On Team or
the members of the add-ons list (all very busy people, who are usually
programmers of some sort, and thus might not be thought of as normal users),
during the brief one-two week open comment period.

I don’t know the discussions behind this proposal, but presumably there is
concern in some circles about clutter on the community site—useless add-ons
that are not desirable, and so a process is being created to stop that from
happening in the future?
If that is indeed a problem we need to solve, maybe we can look at other
potential solutions first?

Luke


From: Mesar Hameed
Sent: Thursday, January 2, 2020 11:14 PM
To: nvda-addons@nvda-addons.groups.io
Subject: [nvda-addons] proposed addon workflow

Dear authors/reviewers.

Thank you for holding off making new releases, and for not pushing any
commits to the new organization repos.

I have written up my thoughts here:
https://github.com/nvdaaddons/nvdaaddons.github.io/wiki/AddonWorkflow

Please have a read, and let me know your thoughts.
Thank you.
Mesar







Luke Davis
 

A couple other thoughts:

 

This proposal now requires a code review, from a supporting reviewer—not just a regular average reviewer--for every stable release of an add-on. In addition to maybe seriously slowing down the speed at which developers can issue new releases to address whatever they may wish, it puts a new load on the Add-Ons Team. Have they agreed to this?

 

Before, the review process just determined that the add-on worked reasonably first-time, and that the author knew what he was doing. Now it will continue to reevaluate those things on an on-going basis, which takes a lot more work (assuming that some frequently updated things don’t just start getting rubber stamped).

 

Again, I question the problem this is trying to solve.

Have there been a lot of cases of already-approved add-ons, having substandard versions uploaded as stable because they weren’t re-reviewed at every upload?

 

I would have less objection if we adopted the trust first, review optionally after, add-ons model that Firefox uses for its extensions.

It would both allow authors to publish stable updates as rapidly as they want, and give the add-on team reviewers the ability to look at an update when they have time, and say “wait a minute, this has a problem”.

The new system gives the add-ons team total content control of add-on stable release versions publicly available on the addons site, so the ability would exist to revert to any earlier version of the add-on.

 

Lastly, the proposal says:

“Therefore the final step of making a release is with the community, not with the addon author, as we want the final product to be fully trusted.”

Well no, it’s not with the community, it’s with the Add-ons Team, in the person of the supporting reviewer assigned to each case when a new stable release is made available. See steps 13-17.

 

That aside, one of the serious problems I see with this model, is that the Add-ons Team, by design, becomes the guarantor of quality. Before the user installed add-ons at her own risk. Do you trust the name of the author? Do you really need the functionality? Then take the risk and install it.

Now we are saying that all you have to do, is trust the add-ons team, because they individually review every code change, and approve them all.

That puts rather a heavy weight on the add-ons team, does it not? And a certain degree of liability that we really will need to disclaim legally somewhere.

And does it really help libraries and schools trust add-ons any more than they do now? It’s still not NV Access itself guaranteeing add-ons.

 

Shouldn’t we be looking at things like add-on signing, or author keys, or other options like that, if we really want to start improving our trust process? We’re raising the hurdle on the community site, and community add-ons, but the back door of non-community add-ons is still wide open, which I think is where all of our past security and trust problems have come from.

 

I apologize if I have misread any parts of this proposal, but some of what it seems to be saying, or some of these things taken to their logical conclusion, are concerning.

 

Luke

 

From: Mesar Hameed
Sent: Thursday, January 2, 2020 11:14 PM
Subject: [nvda-addons] proposed addon workflow

 

Dear authors/reviewers.

 

Thank you for holding off making new releases, and for not pushing any commits to the new organization repos.

 

I have written up my thoughts here:

https://github.com/nvdaaddons/nvdaaddons.github.io/wiki/AddonWorkflow

 

Please have a read, and let me know your thoughts.

Thank you.

Mesar

 

 

 

Noelia Ruiz
 

For me it's reasonable the distinction made by you between add-on team
and community. Or even precissing that the final decission is not by
add-on team, but the assigned support reviewer, though this shouldn't
apply to all stable versions, just to done from master, that is, not
for changes made by the translations system.
I think that, in fact, the last decission is currently done by the
add-on team or people with write or admin to addonFiles. Personally,
when I have been requested or have helped( by authors to release an
add-on version, if they don't have access to addonFiles, in most cases
I have reviewed diffs before releasing them.
The problem is the kind of model we want and what is the purpose of
the website, and even if we can make easy to revoke rights of the
add-on team members, let's say as an example, if someone thinks that I
should be revoked. We should discuss this.
About the model, I think all opinions could be valid and each one
likes one or other. Personally, I think that NVDA doesn't release
stable version too frequently and I agreed when I read something like
they don't want to release in arbitrary periods or time, or that they
prefer to wait even more than three months in the case of NVDA 2019.3,
to offer a product of hight quality. I think add-ons can be released
more frequently, of course, but imo an intermediate solution would be
letting authors to release dev versions and just for very needed or
major changes make a pull request into master.
Other point to discuss is if the community website is or not needed
and why, since add-ons are also posted to different repos, though not
always the author names are reflected correctly, for example. And if
the community website is needed, I think that the workflow can be good
as proposed by Mesar, but really I am flexible and open to your
suggestion, which I find reasonable too.
I will vote for Mesar's workflow, but your model seems reasonalbe too,
and for this reason I'm discussing it.

2020-01-03 10:40 GMT+01:00, Luke Davis <luke@...>:

A couple other thoughts:

This proposal now requires a code review, from a supporting reviewer—not
just a regular average reviewer--for every stable release of an add-on. In
addition to maybe seriously slowing down the speed at which developers can
issue new releases to address whatever they may wish, it puts a new load on
the Add-Ons Team. Have they agreed to this?

Before, the review process just determined that the add-on worked reasonably
first-time, and that the author knew what he was doing. Now it will continue
to reevaluate those things on an on-going basis, which takes a lot more work
(assuming that some frequently updated things don’t just start getting
rubber stamped).

Again, I question the problem this is trying to solve.
Have there been a lot of cases of already-approved add-ons, having
substandard versions uploaded as stable because they weren’t re-reviewed at
every upload?

I would have less objection if we adopted the trust first, review optionally
after, add-ons model that Firefox uses for its extensions.
It would both allow authors to publish stable updates as rapidly as they
want, and give the add-on team reviewers the ability to look at an update
when they have time, and say “wait a minute, this has a problem”.
The new system gives the add-ons team total content control of add-on stable
release versions publicly available on the addons site, so the ability would
exist to revert to any earlier version of the add-on.

Lastly, the proposal says:
“Therefore the final step of making a release is with the community, not
with the addon author, as we want the final product to be fully trusted.”
Well no, it’s not with the community, it’s with the Add-ons Team, in the
person of the supporting reviewer assigned to each case when a new stable
release is made available. See steps 13-17.

That aside, one of the serious problems I see with this model, is that the
Add-ons Team, by design, becomes the guarantor of quality. Before the user
installed add-ons at her own risk. Do you trust the name of the author? Do
you really need the functionality? Then take the risk and install it.
Now we are saying that all you have to do, is trust the add-ons team,
because they individually review every code change, and approve them all.
That puts rather a heavy weight on the add-ons team, does it not? And a
certain degree of liability that we really will need to disclaim legally
somewhere.
And does it really help libraries and schools trust add-ons any more than
they do now? It’s still not NV Access itself guaranteeing add-ons.

Shouldn’t we be looking at things like add-on signing, or author keys, or
other options like that, if we really want to start improving our trust
process? We’re raising the hurdle on the community site, and community
add-ons, but the back door of non-community add-ons is still wide open,
which I think is where all of our past security and trust problems have come
from.

I apologize if I have misread any parts of this proposal, but some of what
it seems to be saying, or some of these things taken to their logical
conclusion, are concerning.

Luke

From: Mesar Hameed
Sent: Thursday, January 2, 2020 11:14 PM
Subject: [nvda-addons] proposed addon workflow

Dear authors/reviewers.

Thank you for holding off making new releases, and for not pushing any
commits to the new organization repos.

I have written up my thoughts here:
https://github.com/nvdaaddons/nvdaaddons.github.io/wiki/AddonWorkflow

Please have a read, and let me know your thoughts.
Thank you.
Mesar







Iván Novegil
 

I think that the need of approval of all the changes will significantly delay the process, in despite of the security it brings. The community has few reviewers to do the tasks that the new workflow would imply in comparison with the previous one.
I think that, although authors can break some development guidelines with it, the previous workflow is better in that respect. If we're already having problems and delays with AddonFiles, with the new workflow they will only increase.

Regards.
---

Iván Novegil Cancelas
Editor
ivan.novegil@...


NVDA.es Logo
Comunidad hispanohablante de NVDA | Proyecto NVDA.es
- www.NVDA.es
- @nvda_es

Usuario do NVDA en galego

***Esta mensaxe e/ou os seus adxuntos están dirixidos ao seu destinatario e poden conter información privilexiada ou confidencial. A utilización, copia ou divulgación dos mesmos por parte de alguén diferente do destinatario mencionado non están permitidas sen autorización. Se recibiu esta mensaxe por erro pregámoslle o comunique por esta mesma vía e a destrúa.***



O 03/01/2020 05:14, Mesar Hameed escribiu:

Dear authors/reviewers.

Thank you for holding off making new releases, and for not pushing any
commits to the new organization repos.

I have written up my thoughts here:
https://github.com/nvdaaddons/nvdaaddons.github.io/wiki/AddonWorkflow

Please have a read, and let me know your thoughts.
Thank you.
Mesar

Lukasz Golonka
 

Hello,

I have to agree with what Luke wrote below. It would not only
potentially eliminate code that someone has already written from being
published on the community website, but even more importantly might
cause some misunderstandings between authors and reviewers. If it is
going to be accepted we should create very clear criteria of what would
be accepted and what would not, but I do not think that this can be
clearly defined.
For example is add-on for the some obscure program that is used by me
and perhaps not one else is going to be accepted or not, and if not why?
The second group of problematic add-ons are these created just for
convenience such as Clock or the add-on for RSS channels (I cannon
recall the name of the top of my head). I personally think that they are,
and it is by no means criticism against authors not really useful, but
as the code has been already written it is very unjust not to accept
them.

Finally I've always thought that the main reason for creating community
add-on website was to make it easier for people to find whatever add-on
they need. If we would start not to accept them developers would have to
publish them somewhere else and fragmentation is not what we want I
believe.



On Fri, 3 Jan 2020 03:46:22 -0500
"Luke Davis" <luke@...> wrote:
�6. Assuming sufficient user interest for the addon to be available on the community website then the author requests that the addon is forked to the nvdaaddons organisation by a supporting reviewer.�

Okay. So obviously an author thinks there is interest, or he would not have written the add-on in the first place. Or he thinks that if he builds it, they may come down the road. I�m sure there are cases of add-ons that were written because somebody was helping himself by writing an add-on, and thought the community would benefit later by having access to it, and released it without an interest study first.
So other than I think this requirement creates a potential catch 22, I wonder who determines whether there is user interest?
Because so far in the process, the author has only published info about the add-on to the add-ons mailing list for code review and comments. This is not the best place to determine user interest, but you are laying an �it has to be interesting enough to the users to be worthy of being on the community site� requirement on all new add-ons.

I dislike the �gatekeepers of user interest� idea that seems to be creeping in here.
The whole point of add-ons, I thought, was to have the broader user community developing for the broader user community. This proposal puts new developers in the position of having to drum up supporters ahead of time to argue for why it�s valuable, before even uploading the first dev version of an add-on.
As I understand it, up until now, if an author wrote an add-on, and it passed reviews of various concrete measurables, it got put on the community site, and we let the users decide if it was interesting. Going forward, interest will be determined in some vague way, by either the Add-On Team or the members of the add-ons list (all very busy people, who are usually programmers of some sort, and thus might not be thought of as normal users), during the brief one-two week open comment period.

I don�t know the discussions behind this proposal, but presumably there is concern in some circles about clutter on the community site�useless add-ons that are not desirable, and so a process is being created to stop that from happening in the future?
If that is indeed a problem we need to solve, maybe we can look at other potential solutions first?

Adriani Botez
 

I Agree with Mesar and his approach. In fact, the official addon website must guarantee security for the user and it must be possible to use it also in corporate environments. Fot this to happen, a structured review process is needed. As of now the official addon website has many outdated addons still, although Joseph already announced the change to python 3 about 3 years ago.

In my view, only following points should be adjusted.Mesar if you want I can raise a pull request for the adjustments:

  • A supporting reviewer can be anyone in the community. Thus, step 12 should be assigned to a member of the addon team, not to the supporting reviewer.
  • If someone from the community reviewed the addon (basic review), then the reviewer can ask on this list for further suport from the addon team. After that, step 12 applies.

 

The suporting reviewer (anyone from the community), should assess on following points:

  1. License and copyright
  2. Readability of the code (description of addon files etc)
  3. Security
  4. Readme (understandable addon description)
  5. User experience
  6. Compatibility

 

  • If these steps are done and the addon passed the basic review, a master branch and a branch “dev version” could be created on community addon repo as a remote to the master of the author’s addon repository (tbd by the addon team and the addon author).
  • Once enough user feedback has been raised, the addon could be declared stable and the commits from author’s master could be merged for the first time to the master of the community addon repository after a pull request has been raised by the addon author.
  • Thus, stable versions are only released from master of community repository, while development versions are released only from the dev branch of the community addon repository.
  • The commits for the development version can be pushed from the addon author to the dev branch of the community addon repository. So the dev branch of the community addon repository is the only branch which allows the author to push commits to without raising pull requests. But the development branch does not synchronize to the translation system.

 

In summary, after the first stable version has been published, the addon team reviews only future stable versions, not development versions.

 

I would not define a minimum time between releases. Every author should be free to decide when he or she wants to release a stable version.

 

Furthermore, specific roles in the addon team are not needed. Since only people with experience are accepted as addon team members, everyone can do what he or she can do the best. If we define roles, there will be even more hierarchical confirmation processes needed. This would slow down addon development even more.

 

Best

Adriani

 

 

Von: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> Im Auftrag von Iván Novegil via Groups.Io
Gesendet: Freitag, 3. Januar 2020 11:21
An: nvda-addons@nvda-addons.groups.io
Betreff: Re: [nvda-addons] proposed addon workflow

 

I think that the need of approval of all the changes will significantly delay the process, in despite of the security it brings. The community has few reviewers to do the tasks that the new workflow would imply in comparison with the previous one.
I think that, although authors can break some development guidelines with it, the previous workflow is better in that respect. If we're already having problems and delays with AddonFiles, with the new workflow they will only increase.

Regards.

---

Iván Novegil Cancelas
Editor
ivan.novegil@...


NVDA.es Logo
Comunidad hispanohablante de NVDA | Proyecto NVDA.es
- www.NVDA.es
- @nvda_es

Usuario do NVDA en galego

***Esta mensaxe e/ou os seus adxuntos están dirixidos ao seu destinatario e poden conter información privilexiada ou confidencial. A utilización, copia ou divulgación dos mesmos por parte de alguén diferente do destinatario mencionado non están permitidas sen autorización. Se recibiu esta mensaxe por erro pregámoslle o comunique por esta mesma vía e a destrúa.***



O 03/01/2020 05:14, Mesar Hameed escribiu:

Dear authors/reviewers.

Thank you for holding off making new releases, and for not pushing any
commits to the new organization repos.

I have written up my thoughts here:
https://github.com/nvdaaddons/nvdaaddons.github.io/wiki/AddonWorkflow

Please have a read, and let me know your thoughts.
Thank you.
Mesar

Adriani Botez
 

Hello,

I think you spend too much thoughts on this user feedback thing. In fact,
even as of now, stable versions are only posted if enough user feedback has
been raised. So the addon is tested at least several weeks after the basic
review and is promoted on the users list before declaring it stable.

Furthermore, the website is not only meant to make it easier to find addons,
but also to guarantee secuirty for users and to make sure people are not
installing malitious code on their PCs. At least stable versions must
guarantee this. Development versions are being used on the responsibility of
the users anyway.

So I agree with the fact that development versions should be published even
there is no or limited user feedback but warn the user that on these
versions only the basic review has been passed.

Best
Adriani


-----Ursprüngliche Nachricht-----
Von: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-
addons.groups.io> Im Auftrag von Lukasz Golonka
Gesendet: Freitag, 3. Januar 2020 12:36
An: nvda-addons@nvda-addons.groups.io
Betreff: Re: [nvda-addons] proposed addon workflow

Hello,

I have to agree with what Luke wrote below. It would not only potentially
eliminate code that someone has already written from being published on
the
community website, but even more importantly might cause some
misunderstandings between authors and reviewers. If it is going to be
accepted we should create very clear criteria of what would be accepted
and
what would not, but I do not think that this can be clearly defined.
For example is add-on for the some obscure program that is used by me and
perhaps not one else is going to be accepted or not, and if not why?
The second group of problematic add-ons are these created just for
convenience such as Clock or the add-on for RSS channels (I cannon recall
the
name of the top of my head). I personally think that they are, and it is
by no
means criticism against authors not really useful, but as the code has
been
already written it is very unjust not to accept them.

Finally I've always thought that the main reason for creating community
add-
on website was to make it easier for people to find whatever add-on they
need. If we would start not to accept them developers would have to
publish
them somewhere else and fragmentation is not what we want I believe.



On Fri, 3 Jan 2020 03:46:22 -0500
"Luke Davis" <luke@...> wrote:
&#65533;6. Assuming sufficient user interest for the addon to be
available on the community website then the author requests that the
addon is forked to the nvdaaddons organisation by a supporting
reviewer.&#65533;

Okay. So obviously an author thinks there is interest, or he would not
have
written the add-on in the first place. Or he thinks that if he builds it,
they may
come down the road. I&#65533;m sure there are cases of add-ons that were
written because somebody was helping himself by writing an add-on, and
thought the community would benefit later by having access to it, and
released it without an interest study first.
So other than I think this requirement creates a potential catch 22, I
wonder
who determines whether there is user interest?
Because so far in the process, the author has only published info about
the
add-on to the add-ons mailing list for code review and comments. This is
not
the best place to determine user interest, but you are laying an
&#65533;it
has to be interesting enough to the users to be worthy of being on the
community site&#65533; requirement on all new add-ons.

I dislike the &#65533;gatekeepers of user interest&#65533; idea that
seems
to be creeping in here.
The whole point of add-ons, I thought, was to have the broader user
community developing for the broader user community. This proposal puts
new developers in the position of having to drum up supporters ahead of
time
to argue for why it&#65533;s valuable, before even uploading the first dev
version of an add-on.
As I understand it, up until now, if an author wrote an add-on, and it
passed
reviews of various concrete measurables, it got put on the community site,
and we let the users decide if it was interesting. Going forward, interest
will be
determined in some vague way, by either the Add-On Team or the members
of the add-ons list (all very busy people, who are usually programmers of
some sort, and thus might not be thought of as normal users), during the
brief
one-two week open comment period.

I don&#65533;t know the discussions behind this proposal, but presumably
there is concern in some circles about clutter on the community
site&#65533;useless add-ons that are not desirable, and so a process is
being
created to stop that from happening in the future?
If that is indeed a problem we need to solve, maybe we can look at other
potential solutions first?

Noelia Ruiz
 

Hi, in fact, fragmentation is already in place. There are add-ons
which haven't been accepted. I can mention for instance saveLog,
Perky, instantBird, just for mentioning add-ons creating by myself.
I think that fragmentation is also even, or has been, for NVDA, where
people posted even portable copies in mailing lists. So I think that
websites should be distinguished by the rules they apply.
If you think, for instance, that readFeeds shouldn't be accepted, it's
ok and debatable. I think that this workflow has the following
advantages:
1. Code writen by admins have to be reviewed.
2. If we agree with the process in place for NVDA, this would be
similar in this respect.
The disadvantage could be the delay of the process, if this is really
a disadvantage.
I think that security would be major since all code has to be
reviewed, as done in NVDA. Imagin that I would like (and please take a
count this is an example), suppose that I accidentally or
intentionally upload harmful code. As an admin this could be not
reviewed, but with this workflow this would be enforzed.
This is my opinion.
Cheers

2020-01-03 12:35 GMT+01:00, Lukasz Golonka <lukasz.golonka@...>:

Hello,

I have to agree with what Luke wrote below. It would not only
potentially eliminate code that someone has already written from being
published on the community website, but even more importantly might
cause some misunderstandings between authors and reviewers. If it is
going to be accepted we should create very clear criteria of what would
be accepted and what would not, but I do not think that this can be
clearly defined.
For example is add-on for the some obscure program that is used by me
and perhaps not one else is going to be accepted or not, and if not why?
The second group of problematic add-ons are these created just for
convenience such as Clock or the add-on for RSS channels (I cannon
recall the name of the top of my head). I personally think that they are,
and it is by no means criticism against authors not really useful, but
as the code has been already written it is very unjust not to accept
them.

Finally I've always thought that the main reason for creating community
add-on website was to make it easier for people to find whatever add-on
they need. If we would start not to accept them developers would have to
publish them somewhere else and fragmentation is not what we want I
believe.



On Fri, 3 Jan 2020 03:46:22 -0500
"Luke Davis" <luke@...> wrote:
&#65533;6. Assuming sufficient user interest for the addon to be available
on the community website then the author requests that the addon is forked
to the nvdaaddons organisation by a supporting reviewer.&#65533;

Okay. So obviously an author thinks there is interest, or he would not
have written the add-on in the first place. Or he thinks that if he builds
it, they may come down the road. I&#65533;m sure there are cases of
add-ons that were written because somebody was helping himself by writing
an add-on, and thought the community would benefit later by having access
to it, and released it without an interest study first.
So other than I think this requirement creates a potential catch 22, I
wonder who determines whether there is user interest?
Because so far in the process, the author has only published info about
the add-on to the add-ons mailing list for code review and comments. This
is not the best place to determine user interest, but you are laying an
&#65533;it has to be interesting enough to the users to be worthy of being
on the community site&#65533; requirement on all new add-ons.

I dislike the &#65533;gatekeepers of user interest&#65533; idea that seems
to be creeping in here.
The whole point of add-ons, I thought, was to have the broader user
community developing for the broader user community. This proposal puts
new developers in the position of having to drum up supporters ahead of
time to argue for why it&#65533;s valuable, before even uploading the
first dev version of an add-on.
As I understand it, up until now, if an author wrote an add-on, and it
passed reviews of various concrete measurables, it got put on the
community site, and we let the users decide if it was interesting. Going
forward, interest will be determined in some vague way, by either the
Add-On Team or the members of the add-ons list (all very busy people, who
are usually programmers of some sort, and thus might not be thought of as
normal users), during the brief one-two week open comment period.

I don&#65533;t know the discussions behind this proposal, but presumably
there is concern in some circles about clutter on the community
site&#65533;useless add-ons that are not desirable, and so a process is
being created to stop that from happening in the future?
If that is indeed a problem we need to solve, maybe we can look at other
potential solutions first?



Lukasz Golonka
 

On Fri, 3 Jan 2020 12:46:52 +0100
"Noelia Ruiz" <nrm1977@...> wrote:

Hi, in fact, fragmentation is already in place. There are add-ons
which haven't been accepted. I can mention for instance saveLog,
Perky, instantBird, just for mentioning add-ons creating by myself.
The question is do we want to decrease fragmentation or not?

I think that fragmentation is also even, or has been, for NVDA, where
people posted even portable copies in mailing lists. So I think that
websites should be distinguished by the rules they apply.
Of course, and this would be happening if the add-ons in the developer
section would be published even if there is no user interest at the
time of review. In the current proposal however this is not the case.

If you think, for instance, that readFeeds shouldn't be accepted, it's
ok and debatable. I think that this workflow has the following
advantages:
I just think, that potentially if I were to review it I might brought up
some objections. However as it is already on the website, and I believe
there is an user base for it it certainly should stay where it is now.
The only way to gain user feedback is to have it pubblished somewhere -
and for most non geeks users author repo on GitHub does not qualify as a
discoverable location.

Adriani Botez
 

Bust to mention, the first development version of an addon needs to pass the basic review in order to

Von be published. Even under the old approach. This should not be changed in my opinion.

Best
Adriani
meinem iPhone gesendet

Am 03.01.2020 um 12:59 schrieb Lukasz Golonka <lukasz.golonka@...>:

On Fri, 3 Jan 2020 12:46:52 +0100
"Noelia Ruiz" <nrm1977@...> wrote:

Hi, in fact, fragmentation is already in place. There are add-ons
which haven't been accepted. I can mention for instance saveLog,
Perky, instantBird, just for mentioning add-ons creating by myself.
The question is do we want to decrease fragmentation or not?

I think that fragmentation is also even, or has been, for NVDA, where
people posted even portable copies in mailing lists. So I think that
websites should be distinguished by the rules they apply.
Of course, and this would be happening if the add-ons in the developer
section would be published even if there is no user interest at the
time of review. In the current proposal however this is not the case.

If you think, for instance, that readFeeds shouldn't be accepted, it's
ok and debatable. I think that this workflow has the following
advantages:
I just think, that potentially if I were to review it I might brought up
some objections. However as it is already on the website, and I believe
there is an user base for it it certainly should stay where it is now.
The only way to gain user feedback is to have it pubblished somewhere -
and for most non geeks users author repo on GitHub does not qualify as a
discoverable location.



Noelia Ruiz
 

Hi, personally I don't like fragmentation, but I think we shouldn't
avoid its increasement by suppressing or not implementing rules if we
think they would increase security and trust.
As you mention, add-ons have to be posted on a public place to be
tested. But I don't know if the website is always the better place for
this. In fact, sometimes people can prefer to attach them on mailing
lists or use personal websites or repos different to GitHub.
I think this workflow is also addressing stable add-ons posted on the
website. I brought up the different labels (more precissely I should
say tags) used on the website like dev, stable and legacy.
But I think that even if fragmentation increases, this workflow
address security since admin code has to be reviewed and ensures we
don't upload add-ons to the stable section if they haven't been
reviewed.
About readFeeds, in case you have objections or some pull request, as
you know I will be happy to consider them :)

2020-01-03 12:59 GMT+01:00, Lukasz Golonka <lukasz.golonka@...>:

On Fri, 3 Jan 2020 12:46:52 +0100
"Noelia Ruiz" <nrm1977@...> wrote:

Hi, in fact, fragmentation is already in place. There are add-ons
which haven't been accepted. I can mention for instance saveLog,
Perky, instantBird, just for mentioning add-ons creating by myself.
The question is do we want to decrease fragmentation or not?

I think that fragmentation is also even, or has been, for NVDA, where
people posted even portable copies in mailing lists. So I think that
websites should be distinguished by the rules they apply.
Of course, and this would be happening if the add-ons in the developer
section would be published even if there is no user interest at the
time of review. In the current proposal however this is not the case.

If you think, for instance, that readFeeds shouldn't be accepted, it's
ok and debatable. I think that this workflow has the following
advantages:
I just think, that potentially if I were to review it I might brought up
some objections. However as it is already on the website, and I believe
there is an user base for it it certainly should stay where it is now.
The only way to gain user feedback is to have it pubblished somewhere -
and for most non geeks users author repo on GitHub does not qualify as a
discoverable location.




Noelia Ruiz
 

Hi, I agree with step 12 modifications proposed by Adriani.
Also, time between releases can be expressed as a recommendation to
make translators work easier, and it could be reflected as already is
done in the guidelines, that maybe linked to this document as
additional recommendations for authors.
About development versions, I think that an author may choose to have
more than one kind of dev version, maybe just to test one feature, so
I think that authors should be free to release dev versions from their
personal account. The problem is how to post them to the website and
if this can or not be automated, or maybe, as Adriani suggest, a
possibility to create dev versions in a way which allows to be posted
on the website in an automated manner.
But imo the biggest change to this workflow affects just admins, whose
code has to be reviewed before beeing posted, as done in NVDA.
Since there are not accepted add-ons, like there are suggestions not
accepted in NVDA's core, though add-ons are more flexible since they
are optional. And about workflow delay, NVDA's workflow is even slower
and require reviews too. I think this shouldn't be a problem,
considering that if an add-on cannot be posted on the website, let's
suppose, in three days or a week, it can be attached or something.
Also if NVDA includes an update feature like Joseph's add-on, maybe
used just for add-ons posted on the website. Otherwise, if the website
doesn't have particular rules, why to maintain it? There are authors
which manage translations contacting translators themselves, or in the
past this was done, so the translations system doesn't justify itself
the existance of the website. If it exists it should or can have
particular requirements, as open as possible.

2020-01-03 12:36 GMT+01:00, Adriani Botez <adriani.botez@...>:

I Agree with Mesar and his approach. In fact, the official addon website
must guarantee security for the user and it must be possible to use it also
in corporate environments. Fot this to happen, a structured review process
is needed. As of now the official addon website has many outdated addons
still, although Joseph already announced the change to python 3 about 3
years ago.

In my view, only following points should be adjusted.Mesar if you want I can
raise a pull request for the adjustments:

* A supporting reviewer can be anyone in the community. Thus, step 12 should
be assigned to a member of the addon team, not to the supporting reviewer.
* If someone from the community reviewed the addon (basic review), then the
reviewer can ask on this list for further suport from the addon team. After
that, step 12 applies.



The suporting reviewer (anyone from the community), should assess on
following points:

1. License and copyright
2. Readability of the code (description of addon files etc)
3. Security
4. Readme (understandable addon description)
5. User experience
6. Compatibility



* If these steps are done and the addon passed the basic review, a master
branch and a branch “dev version” could be created on community addon repo
as a remote to the master of the author’s addon repository (tbd by the addon
team and the addon author).
* Once enough user feedback has been raised, the addon could be declared
stable and the commits from author’s master could be merged for the first
time to the master of the community addon repository after a pull request
has been raised by the addon author.
* Thus, stable versions are only released from master of community
repository, while development versions are released only from the dev branch
of the community addon repository.
* The commits for the development version can be pushed from the addon
author to the dev branch of the community addon repository. So the dev
branch of the community addon repository is the only branch which allows the
author to push commits to without raising pull requests. But the development
branch does not synchronize to the translation system.



In summary, after the first stable version has been published, the addon
team reviews only future stable versions, not development versions.



I would not define a minimum time between releases. Every author should be
free to decide when he or she wants to release a stable version.



Furthermore, specific roles in the addon team are not needed. Since only
people with experience are accepted as addon team members, everyone can do
what he or she can do the best. If we define roles, there will be even more
hierarchical confirmation processes needed. This would slow down addon
development even more.



Best

Adriani





Von: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io>
Im Auftrag von Iván Novegil via Groups.Io
Gesendet: Freitag, 3. Januar 2020 11:21
An: nvda-addons@nvda-addons.groups.io
Betreff: Re: [nvda-addons] proposed addon workflow



I think that the need of approval of all the changes will significantly
delay the process, in despite of the security it brings. The community has
few reviewers to do the tasks that the new workflow would imply in
comparison with the previous one.
I think that, although authors can break some development guidelines with
it, the previous workflow is better in that respect. If we're already having
problems and delays with AddonFiles, with the new workflow they will only
increase.

Regards.

---

Iván Novegil Cancelas
Editor
@inovegil <mailto:@inovegil>
<https://certification.nvaccess.org>


Comunidad hispanohablante de NVDA | Proyecto NVDA.es
- www.NVDA.es <https://nvda.es>
- @nvda_es <https://twitter.com/nvda_es>

Usuario do NVDA en galego

***Esta mensaxe e/ou os seus adxuntos están dirixidos ao seu destinatario e
poden conter información privilexiada ou confidencial. A utilización, copia
ou divulgación dos mesmos por parte de alguén diferente do destinatario
mencionado non están permitidas sen autorización. Se recibiu esta mensaxe
por erro pregámoslle o comunique por esta mesma vía e a destrúa.***



O 03/01/2020 05:14, Mesar Hameed escribiu:

Dear authors/reviewers.

Thank you for holding off making new releases, and for not pushing any
commits to the new organization repos.

I have written up my thoughts here:
https://github.com/nvdaaddons/nvdaaddons.github.io/wiki/AddonWorkflow

Please have a read, and let me know your thoughts.
Thank you.
Mesar






Rui Fontes
 

Hello!

1 - Who is part of "nvda addon team"?
They were , are and will be nominated, appointed, elected? By whom?

2 - Who is considered a "Supporting reviewer"?
Also, they will be appointed by who?

3 - Who will classify an add-on as " Assuming sufficient user interest for
the addon to be available on the community website" or not?

4 - "Therefore the final step of making a release is with the community, not
with the addon author, as we want the final product to be fully trusted."
I can not agree with this...
A) - That way, any synth driver, Braille display driver or any other
commercial add-on will be considered as not being fully trusted!
B) It is not sure that people will be downloading add-ons only from official
repository... Many users even do not know where its located... and they only
install add-ons sent by friends, by users mailing lists or by his NVDA local
team...

5 - If the "nvda addon team" can force the guide lines to write an add-on,
why can not force the possibility of translation?
If we are in a international community and NVDA is developed by NV Access,
and they have this statement in they page:
"OUR MANIFESTO
Access to technology no matter your language, location or financial
situation"
We should make sure that all parts of NVDA can be translated!
Each language team will decide if an add-on needs or not be translated, but
all of them should be translatable and included in the translation workflow.

Best regards,

Rui Fontes
.





-----Mensagem original-----
De: nvda-addons@nvda-addons.groups.io <nvda-addons@nvda-addons.groups.io> Em
Nome De Mesar Hameed
Enviada: sexta-feira, 3 de janeiro de 2020 04:14
Para: nvda-addons@nvda-addons.groups.io
Assunto: [nvda-addons] proposed addon workflow

Dear authors/reviewers.

Thank you for holding off making new releases, and for not pushing any
commits to the new organization repos.

I have written up my thoughts here:
https://github.com/nvdaaddons/nvdaaddons.github.io/wiki/AddonWorkflow

Please have a read, and let me know your thoughts.
Thank you.
Mesar