Labs/Jetpack/JEPs: Difference between revisions
(→Proposed JEPs: Updated JEP 14 - Menus) |
|||
Line 32: | Line 32: | ||
* [[Labs/Jetpack/JEP/24|JEP 24 - Settings]] | * [[Labs/Jetpack/JEP/24|JEP 24 - Settings]] | ||
* [[Labs/Jetpack/JEP/25|JEP 25 - Chrome Boosters]] | * [[Labs/Jetpack/JEP/25|JEP 25 - Chrome Boosters]] | ||
* [[Labs/Jetpack/JEP/26|JEP 26 - Music]] | |||
* [[Labs/Jetpack/JEP/27|JEP 27 - Video]] | |||
= Accepted JEPs = | = Accepted JEPs = |
Revision as of 11:09, 10 September 2009
What is a JEP?
JEP stands for Jetpack Enhancement Proposal. A JEP is a design document providing information to the Jetpack community, or describing a new feature for Jetpack or its processes or environment. The JEP should provide a concise technical specification of the feature and a rationale for the feature.
We intend JEPs to be the primary mechanisms for proposing new features, for collecting community input on an issue, and for documenting the design decisions that have gone into Jetpack. The JEP author is responsible for building consensus within the community and documenting dissenting opinions.
Because the JEPs are maintained on the Mozilla Wiki, the revision history is the historical record of the feature proposal.
The JEP process begins with a new idea for Jetpack. It is highly recommended that a single JEP contain a single key proposal or new idea. The more focused the JEP the better.
Each JEP must have a champion -- someone who writes the JEP, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The JEP champion (a.k.a. Author) should first attempt to ascertain whether the idea is JEP-able. Posting to <mozilla-labs-jetpack@googlegroups.com> is recommended. Small enhancements or patches can generally be put directly into the Jetpack development flow with a patch submission to the Jetpack Bugzilla instance.
Once (or before) a JEP has been accepted by the Jetpack module owners, it is recommended to also make a reference implementation of the JEP and link to it from the JEP's header.
The idea and description of JEPs is borrowed directly from the Python community, often word for word, and their use of PEPs.
Proposed JEPs
- JEP 10 - Clipboard Support
- JEP 11 - Simple Persistent Storage
- JEP 11B - Simple Persistent Storage Alternate
- JEP 12 - Selections
- JEP 13 - Enabling Experimental Jetpack Features
- JEP 14 - Menus
- JEP 16 - SlideBar
- JEP 17 - Page Mods
- JEP 18 - Audio
- JEP 19 - JavaScript Injection Toolkit
- JEP 20 - System Information
- JEP 21 - Toolbar
- JEP 23 - Panels
- JEP 24 - Settings
- JEP 25 - Chrome Boosters
- JEP 26 - Music
- JEP 27 - Video
Accepted JEPs
To become an accepted JEP, ready for implementation, either Atul Varma or Aza Raskin must approve the JEP. At that time, the status will be changed from "Proposed" to "Accepted" and a tracking bug will be created.
Implemented JEPs
After an accepted JEP has been implemented, its bug is marked finished, and its status is changed to "Implemented".