You should expect three distinct phases for your API's development: Proposal, Development, and Going Live.

• You need an LGTM from an Apps & Extensions approver: either miket, kalman, rockot, or benwells @ chromium.org
• You need a second LGTM from a Security approver: either meacer or jww @ chromium.org.

Email the apps-dev@chromium.org mailing list twice: once before implementation (proposal), and once after implementation (final review before Chrome stable).

Need help? Have feedback on this proposal process? Send an email to apps-dev@chromium.org.

Proposal Phase

1. Read the CRX API Security Checklist and make sure your API follows its suggestions.

2. Fill out an API Proposal.

3. Add your API to the Chrome API tracking master document with status "1:proposal."  Make sure to paste a link to your proposal in the appropriate column.  

4. Email apps-dev@chromium.org, cc'ing security-enamel@chromium.org, to say that you have a new API you'd like reviewed, and include a link to your proposal in the email. Suggestion: identify any additional parties or individuals and CC them as well.

5. You’ll get feedback on the apps-dev mailing list. If things are looking good, an Apps & Extensions approver (see top) will give LGTM for the API, and a Security approver (see top) will give LGTM for any security implications.

Development Phase

1. In the Chrome API tracking master document, change the status of your API to "2:coding."

2. Code your extension/app API according to the implementation guidelines.  Your implementation must be kept behind its own feature flag until it works and is secure.  See chrome/common/extensions/feature_switch.h.

3. Write documentation for your API.

1. After your docs are uploaded to codereview, you can preview how it looks at http://developer.chrome.com/_patch/<your CL number>/<your api>, for example http://developer.chrome.com/_patch/14990011/extensions/storage.html.

2. After your docs CL lands, make sure it appears on the dev channel's API page for extensions and/or apps (depending on what your API is targeted for).

4. After your implementation both works and is secure, you should enable your API on the dev channel as described in the implementation guidelines.

5. Encourage usage of the API in the dev channel; the more adoption during dev, the easier your final approval will be.

6. Remain restricted to the dev channel for a full release cycle (in most cases).

7. After receiving and addressing feedback from a few major extensions or apps, proceed to the going live phase.

Going Live Phase

1. Note: Going live must be initiated at least 2 weeks before branch point.

2. Make sure that your API is properly represented in the Chrome API tracking master document.

3. Email apps-dev@chromium.org, cc'ing security-enamel@chromium.org, to say that you'd like a final review for enabling your stable, well-tested API on all channels. You need a second LGTM from an Apps & Extension and Security approver (see top).

4. Have your PM or sponsor file a Type-Launch bug. Your PM or sponsor will usher the API through all of the launch reviews, including privacy and security.

5. Update all sample Extensions or Apps for your API.

6. Land a CL to enable the API for all channels, and change the Status of your item in the Chrome API tracking master document to "3: complete."

7. Work with your PM or sponsor to publicize your new API.