Creating a launch

Open source releases are managed through
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 personal projects that have not gone through IARC, even for
DevRel engineers.

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

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

Calendars

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 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 personal
project, your 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 launch will be
suspended until you reorder them by removing the Open Source calendar and
re-adding it.

Settings on your launch

Eng bit: Add your manager as an approver for the Eng bit

Staging Repository: Include a link to your code on a Git-on-Borg
repostiory 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#organizations 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 assignments
unless specifically instructed to do so.

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.

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.

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.

Personal 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 okay to release.

DevRel, Cloud DevRel, and Ads DevRel releasing

DevRel teams producing 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.

Here’s some handy templates: go/dpe-launch, go/cloud-dpe-launch.

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

Except as otherwise noted, the content of this page is licensed
under
CC-BY-4.0 license.
Third-party product names and logos may be the trademarks of
their respective owners.