Review Process Redesign Proposal

1 view
Skip to first unread message

Jorge Villalobos

unread,
Sep 16, 2009, 2:30:37 PM9/16/09
to
Hello,

My name is Jorge Villalobos and I'm the new Add-ons Developer Relations
Lead at Mozilla.

One of the most challenging tasks of my position consists in improving
the add-on review process, which is currently too slow for most add-on
authors and simultaneously very taxing to our current editor team.

Justin Scott provided a proposal for this some time ago, which garnered
lots of useful feedback. I've used Justin's proposal and your responses
to create this new proposal, which attempts to find the right balance
between the reliability of our current system and the quick review time
that we all want to have.

Please have a look and leave your feedback and questions in this thread.

Doc: http://docs.google.com/View?id=dcxw3w5k_25hn9nd8vg

Thanks!

- Jorge

Gervase Markham

unread,
Sep 17, 2009, 6:01:56 AM9/17/09
to
On 16/09/09 19:30, Jorge Villalobos wrote:
> Please have a look and leave your feedback and questions in this thread.
>
> Doc: http://docs.google.com/View?id=dcxw3w5k_25hn9nd8vg

I think it's important to be clear what is "reliable". It's not the
addon which you are trusting, it's the author (and anyone who has access
to his AMO account).

That being true, what we are looking for is metrics which help us decide
whether an *author* is trustworthy. This is a people problem, not a
technical problem.

If that author is a Mozilla contributor (or even a contributor to
another free software project) that is something we should take into
account. We might even ask authors to provide references from other free
software project leads. That might cover a significant number.

But, if the person is entirely unknown, how do you know whether you can
trust them? I think that the number of updates performed is a poor
metric - the author could write an innocent small extension, update it a
few times, eventually get the flag, and then change it to violate a
user's privacy. And if they were cunning, they'd get away with it for a
while.

I suggest that, instead, a better metric is the _amount of work_ which
has gone into the extension. If an individual developer has spent
hundreds of man hours building an extension and a community, they are
less likely to want to throw all that away.

That means that bigger extensions are more likely to be "reliable" than
smaller ones, older ones than newer ones (to an extent), and ones
managed by teams are more likely than ones created by a single person.

Is that useful?

Gerv

John J. Barton

unread,
Sep 17, 2009, 11:17:47 AM9/17/09
to
Gervase Markham wrote:
> On 16/09/09 19:30, Jorge Villalobos wrote:
>> Please have a look and leave your feedback and questions in this thread.
>>
>> Doc: http://docs.google.com/View?id=dcxw3w5k_25hn9nd8vg
>
> I think it's important to be clear what is "reliable". It's not the
> addon which you are trusting, it's the author (and anyone who has access
> to his AMO account).
>
> That being true, what we are looking for is metrics which help us decide
> whether an *author* is trustworthy. This is a people problem, not a
> technical problem.

+1. So really the editors ought to be interviewing the authors and the
code review, if any, ought to be designed to help new authors learn.

jjb

Jorge Villalobos

unread,
Sep 17, 2009, 11:22:50 AM9/17/09
to Gervase Markham
Gervase Markham wrote:
> On 16/09/09 19:30, Jorge Villalobos wrote:
>> Please have a look and leave your feedback and questions in this thread.
>>
>> Doc: http://docs.google.com/View?id=dcxw3w5k_25hn9nd8vg
>
> I think it's important to be clear what is "reliable". It's not the
> addon which you are trusting, it's the author (and anyone who has access
> to his AMO account).
>
> That being true, what we are looking for is metrics which help us decide
> whether an *author* is trustworthy. This is a people problem, not a
> technical problem.

I agree, and this is why the new system relies on the judgment of an
editor and not a calculated metric.

> If that author is a Mozilla contributor (or even a contributor to
> another free software project) that is something we should take into
> account. We might even ask authors to provide references from other free
> software project leads. That might cover a significant number.

I don't think "open source reputation" is any more objective, and it
would be very hard to verify.

>
> But, if the person is entirely unknown, how do you know whether you can
> trust them? I think that the number of updates performed is a poor
> metric - the author could write an innocent small extension, update it a
> few times, eventually get the flag, and then change it to violate a
> user's privacy. And if they were cunning, they'd get away with it for a
> while.

The idea is to look at the number of updates, the state of the code,
previous responses by editors and authors' reaction to any editor feedback.

The time to nominate an add-on, have it approved and then update it
several times through editor reviews will still take a few months, even
in the new system. And even if you're marked as 'reliable', which you
won't know until you get a 'free' update, all your updates will go
against an automated code check tool and a random probability of being
reviewed by an editor.

It can't be a perfectly safe system because we don't have the manpower
to maintain one. This is what I feel is closest from discouraging any
exploitation while being flexible in the amount of effort required to
maintain it.

>
> I suggest that, instead, a better metric is the _amount of work_ which
> has gone into the extension. If an individual developer has spent
> hundreds of man hours building an extension and a community, they are
> less likely to want to throw all that away.
>
> That means that bigger extensions are more likely to be "reliable" than
> smaller ones, older ones than newer ones (to an extent), and ones
> managed by teams are more likely than ones created by a single person.

In my experience, most add-ons are fairly small and simple, with a
single developer behind them. These are the ones that are taking most of
our time at the moment. I agree these are much more informal projects,
and maybe have a bigger chance of being compromised (on the other hand
big development groups tend the give away their user information just as
easily). But these add-ons are the norm at AMO, and we need a system
that caters specifically to them.

>
> Is that useful?

Absolutely! One of the big unknowns in this proposal is what guidelines
we should give editors and admins in order to decide if an add-on is
'reliable'. You have pointed out some vulnerable points which we need to
account for, so this was very helpful.

>
> Gerv


- Jorge Villalobos

Eric Jung

unread,
Sep 17, 2009, 11:26:35 AM9/17/09
to dev...@lists.mozilla.org

This reminds me of the a Web of Trust (
http://en.wikipedia.org/wiki/Web_of_trust).

Paolo Amadini

unread,
Sep 17, 2009, 2:04:35 PM9/17/09
to Jorge Villalobos
Jorge Villalobos wrote:
> Please have a look and leave your feedback and questions in this thread.
>
> Doc: http://docs.google.com/View?id=dcxw3w5k_25hn9nd8vg

> "All updates for reliable add-ons will have an X% probability of being
> put on hold to be reviewed by an editor. If lucky, the update will be
> pushed to the public immediately."

Actually, as an add-on author, I wouldn't like my submission to be
immediately pushed to the public. If I accidentally made a last-time
packaging error, even if I tested the add-on thoroughly before, the
Firefox installations of all my users would break.

Editors currently do a great service to add-on authors by adding
this safety net between their add-ons and the greater public.

A problem like the one I described actually happened to me once on
mozdev.org, but as soon as I noticed it I was out with a new version
that fixed the problem. A matter of hours.

With the proposed system, it is quite possible that if I made this
mistake with a "free" update, the fixed version I submitted
immediately after could be withheld for an indefinite amount of
time, actually damaging both the users and my reputation.

The review process has multiple purposes. Fulfilling the above
purpose (safety net for mistakes) only requires that an editor
installs the add-on on his testing machine (multiple add-ons
may also be installed at once) and checks that the application
still works. No code review is needed. Until "release channels"
are implemented (allowing authors to allow users to test newer
versions of their add-ons) I think at least an installation by
an editor should be required for every update.

What I would *really* like to be able to do is to mark my updates
as "priority updates". Priority updates must be small enough
to allow a very fast review (or they would not be treated with
"priority"; this is judged by an editor) and must fix a problem
with the latest public version. Editors will ensure that authors
don't abuse this feature (the AMO site may provide a history of
prior priority updates requested for the add-on being reviewed).

I tried to request a "fast update" by sending an e-mail to the
editors mailing list, but my mail was probably ignored (or the
e-mail never arrived, I don't know). I really think this should
be a site feature.

Regarding code review for ensuring that "reliable" add-ons don't
deliberately or accidentally introduce security issues, privacy
issues or policy violations, I think the probability system and
the automated tools may be used to provide "advice" to editors
for whether to do code review for an update at all, or skip it.
New authors would require more attention than experienced ones.
The final decision on skipping the review without even looking at
the code still rests with the editor, that appropriately marks
the update with the "no code review" flag in the review system.
However, this is probably an area that requires input from
experienced editors rather than add-on authors.

Hope this helps,
Paolo

Justin Scott

unread,
Sep 17, 2009, 2:40:49 PM9/17/09
to
I agree that developers should always have the option of keeping an
update experimental and not pushing it public. However, the editors
should *not* be thought of as a personal QA team for every extension. In
their current role, they will catch many problems and it may seem like
it's their job to make sure your extension works perfectly. But their
primary role is ensuring add-ons are safe and of high enough quality to
be published on the site, and Jorge's proposal tries to take that into
account while reducing workload.

Editors should not be expected to hunt for bugs, and I am certainly
against the idea of add-on authors intentionally creating more work for
these volunteers when they should test their work themselves or work
with their community (as many add-ons do) to ensure beta releases work
on all supported platforms before issuing a final update to AMO.

Justin

Jorge Villalobos

unread,
Sep 17, 2009, 2:44:06 PM9/17/09
to

Paolo Amadini wrote:
> Jorge Villalobos wrote:
>> Please have a look and leave your feedback and questions in this thread.
>>
>> Doc: http://docs.google.com/View?id=dcxw3w5k_25hn9nd8vg
>
>> "All updates for reliable add-ons will have an X% probability of being
>> put on hold to be reviewed by an editor. If lucky, the update will be
>> pushed to the public immediately."
>
> Actually, as an add-on author, I wouldn't like my submission to be
> immediately pushed to the public. If I accidentally made a last-time
> packaging error, even if I tested the add-on thoroughly before, the
> Firefox installations of all my users would break.
>
> Editors currently do a great service to add-on authors by adding
> this safety net between their add-ons and the greater public.
>
> A problem like the one I described actually happened to me once on
> mozdev.org, but as soon as I noticed it I was out with a new version
> that fixed the problem. A matter of hours.
>
> With the proposed system, it is quite possible that if I made this
> mistake with a "free" update, the fixed version I submitted
> immediately after could be withheld for an indefinite amount of
> time, actually damaging both the users and my reputation.

Our expectation is to review nominations and updates that have been
thoroughly tested by authors. Our purpose is not to debug or test your
add-on, but to verify that it meets our security and quality standards.

Of course, accidents to happen, and it's great that we are able to
prevent them from causing more damage than they should. However, we're
in a situation were we just don't have the manpower to handle this, and
we need to 'lessen' our system. The ideal system is the one we have now,
where we check every single update, but that's just not possible
anymore, and that's why we need alternatives.

If our editor community were to grow in the future, then we could
certainly tune our variables to bring it back closer to our current
system, say, checking 80% or 90% of all updates.


> The review process has multiple purposes. Fulfilling the above
> purpose (safety net for mistakes) only requires that an editor
> installs the add-on on his testing machine (multiple add-ons
> may also be installed at once) and checks that the application
> still works. No code review is needed. Until "release channels"
> are implemented (allowing authors to allow users to test newer
> versions of their add-ons) I think at least an installation by
> an editor should be required for every update.

I can tell you from personal experience that not all updates are
installed by an editor before they are approved. Sometimes we rely
solely on code differences from previous versions.

> What I would *really* like to be able to do is to mark my updates
> as "priority updates". Priority updates must be small enough
> to allow a very fast review (or they would not be treated with
> "priority"; this is judged by an editor) and must fix a problem
> with the latest public version. Editors will ensure that authors
> don't abuse this feature (the AMO site may provide a history of
> prior priority updates requested for the add-on being reviewed).
>
> I tried to request a "fast update" by sending an e-mail to the
> editors mailing list, but my mail was probably ignored (or the
> e-mail never arrived, I don't know). I really think this should
> be a site feature.

Yes, I also considered the 'priority' flag idea, which me may implement
in the future. However, it wouldn't work all that different from the
mailing list. The problem is that we receive lots of noise from authors
who want their add-ons approved quickly without much justification, so I
think many of us don't take those messages very seriously. I know I have
an important update queued for one of my add-ons, and all I can do is
wait...

Next time you need to do this, please try to be specific as to what is
the problem your users will experience if the update is not pushed
quickly. That may convince an editor to give it special attention.

> Regarding code review for ensuring that "reliable" add-ons don't
> deliberately or accidentally introduce security issues, privacy
> issues or policy violations, I think the probability system and
> the automated tools may be used to provide "advice" to editors
> for whether to do code review for an update at all, or skip it.
> New authors would require more attention than experienced ones.
> The final decision on skipping the review without even looking at
> the code still rests with the editor, that appropriately marks
> the update with the "no code review" flag in the review system.
> However, this is probably an area that requires input from
> experienced editors rather than add-on authors.
>
> Hope this helps,
> Paolo

Thank you very much for your suggestions, Paolo. I'll keep them in mind
when/if we decide to implement this solution.

Jorge

Gervase Markham

unread,
Sep 18, 2009, 7:26:05 AM9/18/09
to
On 17/09/09 16:22, Jorge Villalobos wrote:
> I don't think "open source reputation" is any more objective, and it
> would be very hard to verify.

I am not suggesting it as an objective measure, I am suggesting it as an
answer to a people problem :-)

So, for example, what is the point of doing anything more than a "Duh!
you missed this security problem, fool" code review of addons from MoCo
employees? If they uploaded a malicious addon, they'd get fired. Why
would they do that?

Going more widely, is there much point in looking for evil in the addons
of Gijs Kruitbosch, who has been a community member for years, done
grant-supported work for MoFo, and whom I know well?

Out a bit more: if Linus Torvalds submitted an extension, would you look
for evil? Now, what about Fred Bloggs, of whom Linus says "yes, I've
been working with him on the Linux kernel for a few years, and met him
at OLS - he's a good guy"?

People problems require people solutions, which are messy and
non-quantifiable. I am suggesting that we can reduce the workload of the
AMO editors by using our external community knowledge of who is
trustworthy to reduce the amount of review.

> The idea is to look at the number of updates, the state of the code,
> previous responses by editors and authors' reaction to any editor feedback.

But the number of updates is a gameable metric, as is previous response
by editors and author's reaction. If the addon does cool stuff for a
while, obviously editors are going to like it. If I wanted to get the
editors to trust me so I could exploit the users of my addon, I would
obviously be nice to them.

> The time to nominate an add-on, have it approved and then update it
> several times through editor reviews will still take a few months, even
> in the new system. And even if you're marked as 'reliable', which you
> won't know until you get a 'free' update, all your updates will go
> against an automated code check tool and a random probability of being
> reviewed by an editor.

Right. But will the tool be open source? If so, nefarious people can try
and write code which doesn't trigger it. If not, there's a whole load of
other political issues...

> It can't be a perfectly safe system because we don't have the manpower
> to maintain one. This is what I feel is closest from discouraging any
> exploitation while being flexible in the amount of effort required to
> maintain it.

Absolutely - we're not aiming for perfection. This discussion is all
about bar-raising.

> In my experience, most add-ons are fairly small and simple, with a
> single developer behind them. These are the ones that are taking most of
> our time at the moment. I agree these are much more informal projects,
> and maybe have a bigger chance of being compromised (on the other hand
> big development groups tend the give away their user information just as
> easily). But these add-ons are the norm at AMO, and we need a system
> that caters specifically to them.

We should also consider the number of users. It's far less likely that a
guy with 50 users is going to make his addon nefarious than a guy with
50,000.

Also, how much info do we gather from addon creators? If we knew who
they were, with some level of certainty, it would make them less likely
to do bad stuff. Certificate Authorities have expertise in verifying
identity and encoding it in computer-readable tokens. Can we give a
trust metric boost to people who sign their extensions with a cert which
reaches a certain level of identity validation?

Gerv

Robert Kaiser

unread,
Sep 18, 2009, 7:58:32 AM9/18/09
to
Jorge Villalobos wrote:
> I agree, and this is why the new system relies on the judgment of an
> editor and not a calculated metric.

Tools can mitigate/solve some parts of the problem, of course.
For example,. they can check if a dictionary is really just a
dictionary, which should make it easy to elevate it to public state -
esp. if it comes from a long-time localizer of that language who we as
people know can be trusted as a person (which a tool can't detect, but
which we can tell the system).
Or as another example, if a theme is really only containing skin-type
chrome or a language pack only locale-type chrome, a tool can verify
that and close out a number of classes of things that need review. And
then, a trust level of the person - which we as people need to assess,
not a tool - can turn it over the top to make it public right away.

And even if it might sound egoistic, I think people at a similar level
than me within the Mozilla project should not need editor review unless
requested. It's wasting time to make editors review a new version of
Lightning, ChatZilla, DOM inspector or my LCARStrek theme, editors
should spend this time on getting things reviewed for people that have
not been deeply involved with Mozilla development for ages or had their
code hosted at Mozilla and even shipped within Mozilla products for years.

Robert Kaiser

Jorge Villalobos

unread,
Sep 18, 2009, 12:22:12 PM9/18/09
to Robert Kaiser
Robert Kaiser wrote:
> Jorge Villalobos wrote:
>> I agree, and this is why the new system relies on the judgment of an
>> editor and not a calculated metric.
>
> Tools can mitigate/solve some parts of the problem, of course.
> For example,. they can check if a dictionary is really just a
> dictionary, which should make it easy to elevate it to public state -
> esp. if it comes from a long-time localizer of that language who we as
> people know can be trusted as a person (which a tool can't detect, but
> which we can tell the system).
> Or as another example, if a theme is really only containing skin-type
> chrome or a language pack only locale-type chrome, a tool can verify
> that and close out a number of classes of things that need review. And
> then, a trust level of the person - which we as people need to assess,
> not a tool - can turn it over the top to make it public right away.

That's right. If you look at the proposal, I have made a point of
separating extensions from other add-ons, given that the type of review
and potential threats are very different. We can rely more on tools for
those, absolutely. Right now they take forever to be approved, when in
reality they should be the quickest ones out the door.

>
> And even if it might sound egoistic, I think people at a similar level
> than me within the Mozilla project should not need editor review unless
> requested. It's wasting time to make editors review a new version of
> Lightning, ChatZilla, DOM inspector or my LCARStrek theme, editors
> should spend this time on getting things reviewed for people that have
> not been deeply involved with Mozilla development for ages or had their
> code hosted at Mozilla and even shipped within Mozilla products for years.
>
> Robert Kaiser

I agree that with you and Gerv that add-ons developed by Mozilla don't
require editor review in general. I'm not proposing to remove the
'trusted' status, so they'll continue to have this privilege.

And of course, other authors may gain this status if they have a really
good track record over the years and they become important members of
the Mozilla community.

However, Gerv's example of Linus Torvalds making an add-on and letting
it pass right away is not something I agree with. Having a good
reputation elsewhere shouldn't be 'transferred' here. I'm sure he won't
do anything malicious, but it's still likely that he won't know
everything about add-ons and our policies the first couple of times he
submits anything, and that should be enough to warrant review. I think
authors need to earn their reputation within our community.

- Jorge Villalobos

Majken Connor

unread,
Sep 18, 2009, 2:41:22 PM9/18/09
to Jorge Villalobos, dev...@lists.mozilla.org

> _______________________________________________
> dev-amo mailing list
> dev...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-amo
>

I think I posted this on another discussion, but I think it fits here
again. We're not really trusting the author, we're trusting the author's
_process_. As said above, the point isn't to become QA for authors, good
authors need to do this themselves. While Linus Torvalds might not know the
ins and outs of Mozilla coding, I would hope he'd be familiar with the QA
process. So if Linus Torvalds submits and add-on and says "I had 50 users
testing this for a month with no problems" then we should trust him.

The _process_ is the difference between an author who gets lucky with good
code and an author we can trust. I noticed part of the new developer hub is
a "validator." So, using reputation to establish trustworthiness, we can
then use process (tools and QA) to establish quality.

This metric of how many updates, how well the add-on has performed is really
a grab at guessing how good the author's process is. Why not make asking
this directly part of our process? Also, doing what we can to create tests
and fuzzers that authors can use while developing (and we can use during
submission) will go a long way to helping more authors have a good process,
and saving editors time.

If we have this then we can absolutely use reputation (Mozilla or otherwise)
as a metric for how likely someone will be to try and circumvent good
process and the available tests.

Paolo Amadini

unread,
Sep 18, 2009, 5:26:45 PM9/18/09
to Justin Scott
Thank you very much for the clarification. I never expected editors to
hunt for bugs, however I thought it was their job to help in preventing
an automatic update from breaking the hosting application totally.

Even though that's clearly not an editor's job, the safety net I
mentioned currently exists, at least in part, thanks to the test
installations and/or code reviews that editors do. And mistakes
may happen, potentially even for add-ons like the one I'm maintaining,
that goes through a three-stage incremental release process on
mozdev.org and is thoroughly tested before being pushed to AMO.

What I didn't really consider is that with the new system, when a
package is really broken and is pushed to the public immediately,
an easy way out for authors currently exists: the package can simply
be removed or sandboxed. I guess in this case the previous public
version will become the latest visible version again.

This answers my need. Even though uploading a broken package on AMO
never happened to me, I was ensuring that doing that couldn't be fatal.

Changing subject, have you thought about making code revisions of
removed packages too, in case this feature is deliberately leveraged
to hide an attempt to sneak malicious code through a "free" update?

Paolo

Paolo Amadini

unread,
Sep 18, 2009, 5:47:12 PM9/18/09
to Jorge Villalobos
Jorge Villalobos wrote:
>> What I would *really* like to be able to do is to mark my updates
>> as "priority updates". Priority updates must be small enough
>> to allow a very fast review (or they would not be treated with
>> "priority"; this is judged by an editor) and must fix a problem
>> with the latest public version. Editors will ensure that authors
>> don't abuse this feature (the AMO site may provide a history of
>> prior priority updates requested for the add-on being reviewed).
>>
>> I tried to request a "fast update" by sending an e-mail to the
>> editors mailing list, but my mail was probably ignored (or the
>> e-mail never arrived, I don't know). I really think this should
>> be a site feature.
>
> Yes, I also considered the 'priority' flag idea, which me may implement
> in the future. However, it wouldn't work all that different from the
> mailing list. The problem is that we receive lots of noise from authors
> who want their add-ons approved quickly without much justification, so I
> think many of us don't take those messages very seriously. I know I have
> an important update queued for one of my add-ons, and all I can do is
> wait...
>
> Next time you need to do this, please try to be specific as to what is
> the problem your users will experience if the update is not pushed
> quickly. That may convince an editor to give it special attention.

Actually, I never had the need of a "priority update" until now, I
only asked other questions and whether a localization-only update
could be handled as a "fast update". It was not critical that these
messages received attention, but what I learned is that the current
amo-editors mailing list is probably not a reliable or efficient way
to handle this kind of editor intervention, since editors can't afford
to reply to every message and thus authors don't know if their request
has been considered.

Maybe a counterpart to the amo-editors mailing list, with public
archives, could remove the uncertainty related to the e-mail delivery,
so that at least authors can know that their requests have been read,
even if not accepted.

The alternative can be an automated procedure to request priority
updates. I think that, if well designed, it could guide authors in
understanding when a priority update is appropriate, thus reducing
editor workload for inappropriate requests.

> Thank you very much for your suggestions, Paolo. I'll keep them in mind
> when/if we decide to implement this solution.

Thanks to you for considering them. I wrote some other notes on priority
updates before realizing the was a simpler solution to my problem, as
I said to Justin. If you're interested I may post the notes, or maybe
I could just do that when priority updates are considered in the future.

Regards,
Paolo

Jorge Villalobos

unread,
Sep 18, 2009, 7:30:23 PM9/18/09
to

Please post them here, I'm trying to figure out as complete a plan as
possible. Thanks.

- Jorge Villalobos

Gervase Markham

unread,
Sep 21, 2009, 5:48:42 AM9/21/09
to
On 18/09/09 17:22, Jorge Villalobos wrote:
> However, Gerv's example of Linus Torvalds making an add-on and letting
> it pass right away is not something I agree with. Having a good
> reputation elsewhere shouldn't be 'transferred' here. I'm sure he won't
> do anything malicious, but it's still likely that he won't know
> everything about add-ons and our policies the first couple of times he
> submits anything, and that should be enough to warrant review. I think
> authors need to earn their reputation within our community.

I agree that people won't know the procedures first time. But there are
two sorts of review you could do:

1) I am reviewing this to make sure the person has done everything they
should do (a lot of which can be automated checking)

2) I am reviewing this for the reason above, and also to make sure this
extension isn't going to, accidentally or on purpose, violate user
security or privacy. This requires very careful reading, because the
author may be trying to hide things from me.

2) takes a lot more time than 1). I believe that reputation, even
reputation from other parts of the larger community, can be transferred
in order to move someone's review from category 2 into category 1,
thereby saving editor time.

Gerv

Jorge Villalobos

unread,
Sep 24, 2009, 6:20:37 PM9/24/09
to

FYI, I posted a new version of the document here:
http://groups.google.com/group/mozilla.dev.amo/browse_thread/thread/99bc006e4bad4f78#

It's the same URL, but I hope to hear feedback from all of you to know
what you think about the changes I made.

Thanks!

- Jorge

Reply all
Reply to author
Forward
0 new messages