Getting Approval

(This is part of the process for releasing new open source code. There are different processes for patches and projects that you, or someone not at Google needs or wants to own the IP for your code.)

Prepare
Stage
Get approval 👈 You are here
Release

Creating an Ariane or Launcher2 launch

Launches involving Google Cloud Platform services or teams must use Launcher2 (go/turbo). All other launches should use Ariane. After preparing your project and staging the code on an internal Git-on-Borg repository or Cloud Source Repository, you need to create a launch entry. This includes side projects that have not gone through IARC, even for DevRel engineers.

IMPORTANT: All open source launches must be tracked in Ariane or Launcher2.

TIP: If you are in DevRel and want to release sample code for an already launched product, see DevRel Releasing.

To create an Ariane launch, follow these steps:

IMPORTANT: Open source launches that involve a Google Cloud Platform service or are launched by a GCP employee or team must follow the New Product Introduction (NPI) framework and use Launcher2 tooling. Follow the Launcher2 process at go/oss-Launcher2. All other open source releases should use Ariane launches.

Go to http://linkremoved/
Click "Create Launch"
Add your PA calendar if necessary, see Calendars below, and then search for and add the Open Source calendar.
Complete the rest of the wizard.
On the resulting launch page, fill in the details about your project.
When you are ready, click "Save and start review"
Finally, click the "Request Review" buttons next to every approver to initiate the review process.

To create a Launcher2 launch, follow the steps at go/turbo-user-guide-npi.

Calendars

For Ariane launches, if you are releasing a new open source product (e.g. Kubernetes, Tensorflow, Go, GRPC, Istio), a Google API, or anything involving a new website, hostname, or domain, your Ariane launch must be on your PA Calendar. Add the Open Source calendar as a secondary calendar.

If you are just releasing code (e.g. a tool or library), or it's a side project, your Ariane launch only needs to have the Open Source calendar. (These launches must include the required disclaimer in the project README.)

IMPORTANT: If your calendars are in the wrong order, your Ariane launch will be suspended until you reorder them by removing the Open Source calendar and re-adding it.

For Launcher2, follow the OSS Launch guidance at go/oss-Launcher2.

Settings on your Ariane launch

Eng bit: If you are releasing a project as part of the 2020 Google Internship program, see instructions below. Otherwise, set this bit to your manager.
Staging Repository: Include a link to your code on a Git-on-Borg repository or Cloud Source Repository in the URL for Staging Repository field.
GitHub URL: Include the GitHub URL of where you would like to publish your code. Follow guidance in go/github-docs/where as to which organization to use, and when you may publish in your personal account.
Approvers: Do not set any approvers' bits to FYI or change the approvers unless specifically instructed to do so. (The opensource-patents bit is set to FYI by default, and you should leave it set that way unless you have specific patent-related concerns.)
Website: If you are creating a new website/domain with your launch, select "Yes" for the Website Launch field. This requires that you add your PA calendar as the primary calendar to your launch, and the Open Source calendar second.

TIP: You can look at a sample Ariane launch to see how an Ariane launch should look.

Settings on your Launcher2 launch

For Launcher2, follow the OSS Launch guidance at go/oss-Launcher2.

Getting approval

Once your Ariane or Launcher2 launch is created, follow these steps:

Ensure all reviewers have read access to your code.
Address any comments or issues posted by the launch reviewers.
If a field has a "Request Review" button, request review.
If a field is marked "Pending Review", wait for approval.

During review, some of the major things reviewers look for include:

That it doesn't include anything linked to Google's "secret sauce" (e.g. ranking, filtering, etc...).
That sharing helps users, not just our competitors.
That any non-Google code is in a third_party directory.
That it is in license compliance with any third-party dependencies.
That it doesn't violate a country's laws.
There are no patent issues.
There are no privacy issues (see below).

A legal review will be required if your code collects any data about users and transmits it back to us or if it affects or transmits third-party content. We'll add the right people to the launch calendar entry, but if you mention this in the description, it will help speed things up.

All launches that include machine learning artifacts such as code, pre-trained models, or datasets are additionally reviewed for compliance with Google's AI Principles.

We'll use the launch calendar entry to ask questions and discuss any potential problems, but it's generally a smooth process. Once you receive full approval, continue on to the next step in this process.

Eng Approval

NOTE: This section provides guidance for the Eng reviewer.

The Eng reviewer should primarily seek to answer the question, "Is this project okay to release?". We ask the launch creator's manager to make this call, since the Open Source Office often does not have the appropriate context to do so. If the manager does not feel comfortable making this determination, or for larger launches that warrant more senior review, it's always okay to have a director or VP do this review.

We generally encourage approving releases unless there's a good reason not to, but if you have any questions, you can reach out to emailremoved@.

Examples of work-related projects that might not be okay to release include:

A proprietary algorithm we want to keep internal for business reasons
One that competes with other Google projects or interests in a way that is undesirable (note that this kind of competition between projects is often okay)
Projects that don't yet meet some team-specific criteria for release, such as test coverage, documentation, etc.

Not all of these will apply for every launch, and it is common for projects that are releasing existing Google code to receive a more thorough review.

Side projects a Googler may be working on in their 20% time or personal time often do not require as much scrutiny, but you should still check for the same thing: whether the project is okay to release.

DevRel, Cloud DevRel, and Ads DevRel releasing

IMPORTANT: DevRel teams in GCP or working on GCP products must follow the New Product Introduction (NPI) framework and use Launcher2 tooling.

DevRel teams outside of GCP producing official sample code and example applications directly related to a released Google product may go through the expedited approval process by writing "DEVREL" in the notes for the Eng bit and flipping the bit yourself. If a launch is not complete within 3 business days of filing, please email emailremoved@ directly.

DevRel teams may use private GitHub repos to stage code related to I/O or marketing deadlines, but only after licensing and patents approval on the launch calendar. They must specify a fixed and reasonable deadline for deleting the repo or making it public.

An Ariane template for DevRel launches is available at go/dpe-launch.

Additional instructions for DevRel teams can be found at go/dpe-oss and go/gcp-github.

2020 Internship releasing

NOTE: Ariane or Launcher2 launches for internship projects should be completed by the Googler host.

Projects being released during the 2020 internship season have special requirements for the Eng approval bit:

If you will be open sourcing existing Google-owned code as part of the internship project, the host should set the Eng approval bit to their Director.
If the project does not involve releasing any existing Google code, the host should write 2020 INTERNSHIP in the notes for the Eng bit and flip the bit to Approved.