Gecko BD Guidelines

When partners request Gecko features, consider the following:

• We need descriptions that are clear enough for engineers to understand the scope. We also need a description of why the partner need the feature. I.e. what end-user functionality they are trying to build.

• It's rare that we get enough details in an initial request that we can go off and build the feature. Generally we need to talk engineer to engineer with the partner to hammer out details.

• Staff who are going to work on a feature should sign off before we agree to it (including work needed on dependencies).

• Features accessible to Web sites. Web-visible features must have a public specification. There are some specs we don't want to implement, so check with staff (module owners) whether an existing spec is one we're willing to implement. If there is no spec, we can work with a partner to create one. This includes extensions to existing features. The reason this is needed is because once we expose a feature to the web, we essentially commit to supporting that feature indefinitely.

• Features that are only exposed to "privileged" FirefoxOS apps are easier to build than features exposed to the web. However they still require significant design work since we have to support the feature for a very long time.

• Restricting features to "internal" apps (that ship with the device) is much easier --- especially if the partner can ship the feature(s) by applying their own patches to Gecko.