Want to contribute? Great! First, read this page (including the small print at the end).

Before you contribute

Before we can use your code, you must sign the Google Individual Contributor License Agreement (CLA), which you can do online. The CLA is necessary mainly because you own the copyright to your changes, even after your contribution becomes part of our codebase, so we need your permission to use and distribute your code. We also need to be sure of various other things—for instance that you‘ll tell us if you know that your code infringes on other people’s patents. You don‘t have to sign the CLA until after you’ve submitted your code for review and a member has approved it, but you must do it before we can put your code into our codebase.

Before you start working on a larger contribution, you should get in touch with us first through the issue tracker with your idea so that we can help out and possibly guide you. Coordinating up front makes it much easier to avoid frustration later on.

Code reviews

All submissions, including submissions by project members, require review. We recommend forking the repository, making changes in your fork, and sending us a pull request so we can review the changes and merge them into this repository.

Functional changes will require tests to be added or changed. The tests live in the test/ directory for each package, and are run with dart test. If you need to create new tests, use the existing tests as a guideline for what they should look like.

You can run all additional presubmit checks locally if you wish, by using the mono_repo tool. From the root of the repository, run pub global run mono_repo presubmit.

Versioning

You will also need to potentially update the pubspec.yaml and/or CHANGELOG.md of any package you are updating. If the current version is not a -dev version then you should update it and add a new header to the changelog. If you have no publicly facing change to list, it is OK for there to be no changes listed.

We follow pretty strict semantic versioning, feel free to ask on the PR if you are unsure about what version number you should choose (or do your best, and a code reviewers will bring it up if it is incorrect).

File headers

All files in the project must start with the following header.

// Copyright (c) 2023, the Dart project authors.  Please see the AUTHORS file
// for details. All rights reserved. Use of this source code is governed by a
// BSD-style license that can be found in the LICENSE file.

Publishing

Publishing is done by package owners creating a tag of the form <package>-v<version>, either manually or through the github release ui (preferred). The pubspec and changelog must already be updated to the desired release version in the master branch for this process to work.

The small print

Contributions made by corporations are covered by a different agreement than the one above, the Software Grant and Corporate Contributor License Agreement.