Archive for the ‘policy’ Category

Add-on Review Process Redesign

Thursday, October 1st, 2009

Hello.

My name is Jorge Villalobos, and I’m the new (first, really) Add-ons Developer Relations Lead at Mozilla. I’ll be working on bringing the add-on developer community and Mozilla closer together. I have been an add-on developer for over 2 years, working on around a dozen add-ons during that time. I’ve worked on a few independent projects as well, Fire.fm being the most successful one, and the one I’m most proud of.

My initial focus in this role at Mozilla is to reduce the add-on review waiting times to a point where authors can have some certainty that their add-ons will be reviewed within a reasonable time frame. The current state of the queues is far from ideal, with the recent release of Firefox 3.5 being a big contributor to the rising tide of submissions. The queues are long, and add-on authors are not happy. I actually have a somewhat important update for Fire.fm waiting in the update queue, and I can’t help but feel a bit impatient about it.

To solve the queue situation, we are working on several solutions. We’re constantly looking for and introducing new editors to our team. We are working more closely with them to understand how they work and what their concerns are, and also to focus their efforts in the areas that have the greatest needs. We are attacking the queue problem from several different angles, some which will help us in the short term, and some which are more forward-looking, such as the one I’m introducing here.

We want to change how we handle add-on reviews, specially for updates. Our current system doesn’t handle well the fact that there are add-on authors that no longer need to have the constant scrutiny of the editor team, and don’t need to have their updates reviewed every single time. We think we need to introduce a trust factor into the process, that allows us to give more freedom of publication to authors that have proven themselves trustworthy. There are plenty of those, and I bet they are the most active authors on AMO. Reducing the amount of update reviews we give to trusted authors will give more time to our editors to focus on new add-on nominations and other updates, significantly reducing waiting times and making everybody happy.

I also cover some ideas for reviewing add-ons that are not extensions, which usually have longer waiting times when in reality they should be the easiest to check.

If you’re interested in the details, please read the proposal on Google Docs: Review Process Redesign Proposal. It’s very short, so it shouldn’t take more than a couple of minutes to read. You can take part in the discussion of the proposal in the mozilla.dev.amo newsgroup, or post a comment here. I’ll try to respond to all as time permits.

Coming Up for AMO

Thursday, August 20th, 2009

We launched Collections in June, Contributions in July, and the response to both has been amazing. What’s next for AMO? Here are some summaries of our upcoming projects.

Collections Phase II

Screenshot of recommended add-ons boxWe’ve had over 27,000 collections created and 6.5 million add-on downloads from those collections since the launch on June 10. We want to add a number of new collection features to the website and Add-on Collector extension, including:

  • collection ratings
  • statistics dashboard for collection creators
  • add-on recommendations based on collection data
  • recently viewed collections
  • Thunderbird & Fennec support for the Add-on Collector

Check out this spec for all the details planned for this second phase. If you have feedback on this, please post it in this newsgroup thread. The website features above are included in AMO 5.0.9, which should be released at the end of next week.

Add-on Developer Hub

Developer Hub Homepage Mock-upIn May, we posted about our plans for a new one-stop-shop for add-on developers. Whether you’re someone new to Firefox and not sure if you want to write an extension, a long-time developer looking to stay up-to-date on add-on news and documentation, or an add-on author wanting to update your AMO listings, the Add-on Developer Hub at AMO will be the place to go.

Among the features of the new developer area are:

  • add-on case studies
  • AMO policies
  • how-to library/portal
  • API/Language reference links
  • add-on builder (extension skeletons with working UI components)
  • add-on validator

You can see some mock-ups of what the new site will look like here, or view the spec for all the details. Please post any feedback in this newsgroup thread. We’re planning this for AMO 5.1, which should be released in late September.

Disclosure of Add-on Practices

Disclosure of Add-on Practices checkboxesMany add-on authors, individuals and companies alike, invest large amounts of time and effort into their add-ons, and wish to be compensated for their work. Although we have launched the Contributions feature for authors to accept donations from users, some authors have partnered with companies to support the continued development of their add-on in exchange for the add-on making certain changes to Firefox. We enacted a No Surprises policy in an effort to protect user choice, but unfortunately continue to find surprises.

We feel it is necessary for users to know about certain add-on practices that an add-on employs prior to installation. These practices must be disclosed in a clear and consistent way across AMO. Our plan for this is described in this spec. Please post any feedback in this newsgroup thread.

Add-on Compatibility Reporter

Compatibility Reporter Mock-upNew versions of Firefox are always in the works, and the lead-up to a final release can be hectic for both add-on developers and the AMO team as we try to encourage everyone to test and update their add-ons in the new version. We’ve come up with an idea for an Add-on Compatibility Reporter extension that would be bundled with alpha and beta builds of Firefox and facilitate add-on testing and reporting.

If you have add-ons installed that don’t work, you can report that to AMO. If you have incompatible add-ons installed that work fine, you can report that to us too. We’ll look at all the submitted reports and email developers when we think we know whether the add-on is compatible with that Firefox version, or if it’s not compatible and what problems users are having.

For all the details, you can read the spec. If you have feedback, please post in this newsgroup thread.

As you can see, we have a lot going on, including several projects not mentioned here. Stay tuned to the newsgroup and this blog for the latest on add-ons.

Removing the Sandbox

Wednesday, July 1st, 2009

The “Sandbox Model” addons.mozilla.org uses to organize and review add-ons was first announced almost 3 years ago. Since then, we’ve made a number of changes based on user feedback that, in my opinion, have greatly improve the experience of finding and installing add-ons that haven’t been officially reviewed yet.

Today, the main feedback concerning the review and distribution process of add-ons is:

  • developers feel it takes too long for add-ons to be reviewed, and
  • users and developers want to receive updates to add-ons that they have installed that haven’t been reviewed yet

It’s important for us to balance our desire for all add-ons to be discoverable and easy to install with the need for security measures for add-ons that haven’t been reviewed yet.

After taking many of these issues into account, I’ve come up with a proposal for removing the public and sandbox classifications on the site and moving to a more flexible, comprehensive trust system based on everything we know about an add-on. If you’re interested in the review process and distribution of add-ons, please read the proposal and give us your feedback, preferably in this newsgroup thread.

No Surprises

Friday, May 1st, 2009

Surprises can be appropriate in many situations, but they are not welcome when user security, privacy, and control are at stake. Mozilla is committed to guarding these principles, and we feel that a policy should be adopted that explicitly details our stance on these issues in regard to add-on modifications. The text of our proposal is below.

Changes to default home page and search preferences, as well as settings of other installed add-ons, must be related to the core functionality of the add-on. If this relation can be established, you must adhere to the following requirements when making changes to these settings:

  • The add-on description must clearly state what changes the add-on makes.
  • All changes must be ‘opt-in’, meaning the user must take non-default action to enact the change.
  • Uninstalling the add-on restores the user’s original settings if they were changed.

These are minimum requirements and not a guarantee that your add-on will be approved.

We welcome all constructive feedback and comments on this proposal, preferably in the AMO Newsgroup.

New Developer Agreement

Friday, May 1st, 2009

Up until now, we’ve had a fairly basic developer agreement that hasn’t changed with the needs of our developers and our service. Today, we’re launching a new agreement that clarifies and protects our developers’ rights and ensures that we can continue to promote add-ons via multiple ways and channels as our service expands.

That’s why we’ve launched an updated developer agreement. For those of you not well versed in legalese, here’s what we did and why we did it:

We had four primary goals in revisiting the language in our agreement with add-on developers:

  • To ensure that users have the opportunity to access and understand their rights to your add-ons. Access to relevant license agreements was hit or miss in years past, some developers provided a license agreement and others did not. Under our new agreement and registration process, developers will need to identify and provide a copy of the license agreement that governs use of their add-on. We believe this process will provide greater transparency for users and will help protect developers from unwanted/unauthorized use of their add-on.
  • To ensure that Mozilla has the rights it needs to provide the add-on service. As we continue to promote the service, it’s become clear that the rights that Mozilla will need are not always identical to the rights that developers give to individual users (such as the right to distribute an add-on). As such, we’ve introduced a license specifically for Mozilla that will enable us to continue providing and enhancing the add-on delivery service and that also provides developers with a better idea of how we use their content and the limitations/boundaries of such use.
  • To ensure that our rights and activities relating to management of the add-on service are more clearly articulated. While this point was addressed briefly in our prior developer agreement (for example, it referred to our right to re-categorize or change an add-on’s listing), we wanted to make sure that we have the flexibility needed to address concerns/issues that arise in the future and to also provide our developers with a more detailed description of how we currently manage the service.
  • To more specifically address the AMO API. We’re delighted that the AMO API has become a popular feature of the add-on service. However, along with this popularity, we’ve experienced some individuals using the feature for purposes for which it was not designed or intended. So, we’ve included language to more clearly define how developers may use the AMI API feature.

Please let us know if you have any questions via the AMO Newsgroup.

Edit: See both versions of the developer agreement here

The How’s & Why’s of the AMO Recommended Rotation

Tuesday, March 10th, 2009

What are the Recommended Lists?

The Recommended lists are an important part of exposing AMO visitors to useful and compelling add-ons within a small & focused list. It allows us to feature add-ons that have done a good job of creating a unique and/or exciting enhancement to Mozilla software and increasing awareness of the nearly 8,000 add-ons hosted on AMO. The Recommended lists are broken down into two categories; Recommended and Category Recommended. The former is shown on the home page of AMO and is typically limited to 40 featured add-ons. The latter are lists of add-ons that are recommended at the category level. The only distinction between the two lists is that Category Recommended add-ons are not featured on the home page. Apart from that, both lists are meant to recognize the achievements of individual add-on authors and the work they’ve produced.

Every month, we perform a rotation of the AMO Recommended lists. The reason that we do this is to allow visitors to discover new & exciting add-ons to customize their software with. AMO consumers look for freshness and having the same add-ons featured monthly can make things a bit stale. Unfortunately, the monthly rotation and the methods used in determining which add-ons will be included has been a point of concern for many add-on authors. The lists are a great method to acquire more users and as such, authors work hard to get added to, and stay on, the lists. Being removed for any reason is usually a cause of concern and hopefully, this blog post will help to address the rationale behind our decisions.

The Methods Behind the Rotation

The rotation is primarily based on statistics we’ve collected to determine if an add-on:

  1. Is performing well and should be considered for Recommended or Category Recommended status
  2. Is benefiting from the Recommended lists once they’re added

The barometer that we’ve used to date to determine if an add-on should be considered for recommended status is when it’s reached at least 15-20k active users. This ensures that an add-on has gained traction, is considered popular by the community and also demonstrates that an add-on author is serious about his/her work. At times, we’ve been flexible and extended add-ons which were under that metric an opportunity to be featured especially if they were extremely unique or buried in a very busy category. On other occasions, we’ve received recommendations from someone and after finding that the add-on was indeed useful, we’ve added them on.

The methods used to generate these stats are simple. We look at pings (active users), downloads, & reviews. Before adding any add-on to the recommended lists, we physically go to their profiles and look at the reviews to see if the add-on has a number of negative reviews and if so, has the author at least attempted to resolve it. User reviews help us to determine if:

  • Users are finding the experience rewarding
  • The author is actively responding to any user concerns

Having lots of negatives reviews will count against a add-on and could lead to not being considered for recommended status or removal from the recommended lists.

Once an add-on has been added to the recommended lists, we look at the add-on’s monthly stats to determine how well it’s performing. Typically, a add-on added to the lists will see an increase in user interest and should theoretically see an increase in both downloads and active users.The stats will tell us if a add-on has increased in both downloads and active users during the previous month that they were on the list. If they’ve benefited slightly, we generally keep them on the recommended lists to see if an additional month will help them increase their users. If they’ve not benefited (eg: a drop in user retention or lack of downloads) and they were listed as Recommended (featured & on the main page), we will either drop them to category recommended or, if the decline in metrics is substantial, remove them from the lists entirely. Again, stats + reviews is what we use to determine a add-ons performance.

The point is that if a add-on is placed on the recommended lists and is not benefiting from the increased exposure, it does not make sense to continue to list them on there. Add-ons that are on the recommended lists typically experience a substantial gain in both downloads and active users so if an add-on is not demonstrating growth in any substantial way, that’s a very good indicator that the add-on may not be that attractive to AMO visitors.

The newest thing that we’ve been looking at is length of time on the recommended lists. The lists are meant for *ALL* developers to have a chance to be featured, not a select few who are either name brands or well-funded. It’s one of the reasons that there have been a number of add-ons who have been recommended for over 12 months being rotated out. This is a good thing as it allows more add-ons a chance to get exposure and it addresses one of the biggest complaints we heard at Add-on-Con; hobbyists don’t get any attention on AMO. In this last rotation alone, we’ve received kudos from small add-on developers thanking us for finally getting on the list. That speaks volumes.

Firefox Beta Compatibility and Recommended Status

Lastly, an EXTREMELY important requirement for being recommended is to be up-to-date with the most current beta version of Firefox. The number of add-ons that have been passed by due to not supporting the latest Firefox beta build (currently 3.1b2) is staggering. We’ve been announcing since December, 2008 that add-ons authors who wish to have their add-ons considered for recommended status must ensure that their add-ons are compatible. We’ve posted several articles about this and made resources available to easily update your add-ons.

This entire process isn’t perfect and it’s one of the reasons that we’re looking to expand the distribution channels available to developers. Getting everyone more avenues for additional exposure is a top priority for Q2 and we’re focused on improving the process.

Changes to the Featured & Recommended add-ons on AMO

Thursday, April 24th, 2008

One of the main goals for AMO is to help introduce add-ons to the user base of Firefox (and other other apps supported on AMO). The recommended list has been one of the ways to do that.

Prior to AMO v3.2, a single list of add-ons was maintained that showcased a sample of what can be done with add-ons. This came to be known as the “Recommended List”. Participation in the recommended list was coveted by authors since it was one of the more visited pages on the site and meant your add-on got downloaded more. AMO currently receives about 5 million pageviews per day with approximately 3% of the traffic to the recommended list. The list has grown and changed over time but has had about 25 add-ons on it. With a single list, the members of the recommended list got the most attention and “starved out” visibility for other add-ons.

One of the changes that was introduced with the latest AMO redesign is the ability to highlight a wider variety of add-ons. Instead of a single list, recommendations are now on a per-application, per-category and a per-locale basis. This gives the community greater flexibility and  increases the face time and exposure (impressions) that an add-on can have.

With AMO 3.2, we now have many lists.

  • Category-Recommended lists are edited lists managed by the AMO editors. They represent a list of the most interesting add-ons for a particular category.
  • Category-Recommended add-ons appear on:
    • One of the two slots in the AMO category landing page (see sample)
    • The Recommended List page for that category (see sample)
    • The default view in the “Get Add-Ons” panel in the Firefox 3 Add-Ons Manager (once this bug is fixed).
  • We anticipate about 5-10 recommended add-ons per category. (Fuzzy math: 14 categories x 10 add-on/category = 140 recommended. Approximately 5000 add-ons on AMO means 3% are recommended.)
  • As AMO editors are constantly reviewing add-ons, they can opt to showcase promising add-ons
  • Add-on authors can request to become recommended (see last question)
  • The Featured list is an edited list managed by the AMO administrators and editors that showcases add-ons for a period of time. This list will have add-ons rotate into and out of it on a periodic basis. Currently, once every 3-4 weeks. The list will be chosen from the existing set of Category-Recommended add-ons.
    • Members of the Featured list will be rotated into one of three slots on the front page of AMO
    • In order to ensure that the feature list maintains a wide sampling of add-ons from various categories, not all add-ons will be swapped out since some categories will need representation.
    • We anticipate about 20-30ish add-ons to be on the featured list at any one time
    • Currently, the following add-on categories will not be chosen for participation in the Featured list: Web Development, Language Tools & Toolbars. This may be revisited at a later date.

So, check out the new AMO site and the latest batch of Category-Recommended add-ons as well as the most recent rotation of Featured add-ons.

We’ve tried to outline a policy around how all this will be managed – if you’d like to read and review the gory details on how the featured and recommend lists work – check this out. Feedback is appreciated as we are trying to be as transparent as possible. There’s more to do in this area including clarifying some edge cases on policy, considering whether to recommend themes and building locale-specific Category-Recommended and Featured lists.