Update:Future Direction: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
| Line 18: | Line 18: | ||
== Option #1: Separate finished from in-progress extensions == | == Option #1: Separate finished from in-progress extensions == | ||
* Addons at v1.0 and higher are subject to a full QA/evaluation process that rates the addon against Mozilla release standards. This is intentionally a high bar, and a longer process, but should result in a subset of high quality extensions that we expose by default. | |||
* Addons versioned < 1 are not shown on the main site, but are available via a second site backed by the same backend instance. These are then not subject to testing, and an admin can simply review the submission and approve it for the site. | * Addons versioned < 1 are not shown on the main site, but are available via a second site backed by the same backend instance. These are then not subject to testing, and an admin can simply review the submission and approve it for the site. | ||
Issues: | Issues: | ||
* Some addons may be versioned > 1 and not meet our quality standards. Possibly ignore version and have the author flag for official sanctioning of some sort? | * Some addons may be versioned > 1 and not meet our quality standards. Possibly ignore version and have the author flag for official sanctioning of some sort? | ||
* If and when we get signing etc working does this get added to the process for the main (vetted) site? | * If and when we get signing etc working does this get added to the process for the main (vetted) site? | ||
== Option #2: Only support/host release-quality extensions == | |||
* Addons are held to the release quality standard as in #1 | |||
* Extensions not meeting this standard can host elsewhere | |||
Issues: | |||
* Less community building, more focus on testing and (effectively) certifying a smaller set of extensions | |||
* Pushes new innovations outside of mozilla.org | |||
Revision as of 21:53, 9 January 2006
Before we embark on significant work to enhance and drive the site forward, we should stop to consider what direction the site itself will take through the next year.
Known Issues
- Performance and scaling
- This will be addressed on the public-facing elements of the site by reimplementing using the Smarty PHP templating engine and a PHP accelerator to aid caching and flexibility (ETA: mid/end Jan)
- Review/approval backlog
Site Managment options
Current setup
- Editorial standard is "works and plays nice"
- All extensions are tested and reviewed on all supported platforms before availability
Issues:
- Unpredictable quality/polish/level of user experience
- Review queue simply doesn't scale without dedicated staff, leading to large backlogs and long delays in publishing updates (even simple version bumps)
Option #1: Separate finished from in-progress extensions
- Addons at v1.0 and higher are subject to a full QA/evaluation process that rates the addon against Mozilla release standards. This is intentionally a high bar, and a longer process, but should result in a subset of high quality extensions that we expose by default.
- Addons versioned < 1 are not shown on the main site, but are available via a second site backed by the same backend instance. These are then not subject to testing, and an admin can simply review the submission and approve it for the site.
Issues:
- Some addons may be versioned > 1 and not meet our quality standards. Possibly ignore version and have the author flag for official sanctioning of some sort?
- If and when we get signing etc working does this get added to the process for the main (vetted) site?
Option #2: Only support/host release-quality extensions
- Addons are held to the release quality standard as in #1
- Extensions not meeting this standard can host elsewhere
Issues:
- Less community building, more focus on testing and (effectively) certifying a smaller set of extensions
- Pushes new innovations outside of mozilla.org