Skip to content

Latest commit

 

History

History
124 lines (95 loc) · 5.53 KB

CONTRIBUTING.md

File metadata and controls

124 lines (95 loc) · 5.53 KB
Raw

Contributing

See also: Flutter's code of conduct

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

Is this the right place for your contribution?

This repo is used by members of the Flutter team and a few partners as a place to store example apps and demos. It's not meant to be the one and only source of truth for Flutter samples or the only place people go to learn about the best ways to build with Flutter. What that means in practice is that if you've written a great example app, it doesn't need to be maintained here in order to get noticed, be of help to new Flutter devs, and have an impact on the community.

You can maintain your sample app in your own repo (or with another source control provider) and still be as important a part of the Flutter-verse as anything you see here. You can let us know on the FlutterDev Google Group when you've published something and Tweet about it with the #FlutterDev hashtag.

So what should be contributed here, then?

Fixes and necessary improvements to the existing samples, mostly.

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.

A few ground rules

This is monorepo containing a bunch of projects. While different codebases have different needs, there are a few basic conventions that every project here is expected to follow. All of them are based on our experience over the last couple years keeping the repo tidy and running smooth.

Each app should:

  • Be designed to build against the current stable release of the Flutter SDK.
  • Include the same analysis_options.yaml file used throughout the repo. These files include a base set of analyzer conventions and lints.
  • Have no analyzer errors or warnings.
  • Be formatted with flutter format.
  • Include at least one working test in its test folder.
  • Be wired into the list of projects in the CI script, which runs the analyzer, the formatter, and flutter test.
  • Avoid adding an onerous amount of blobs (typically images or other assets) to the repo.

In addition, sample code is, at the end of the day, still code. It should be written with at least as much care as the Flutter code you'd find in the SDK itself. For that reason, most of the Flutter style guide also applies to code in this repo.

The experimental folder

Projects in the repo's top-level experimental directory are allowed to skirt some of the above rules. These apps are either experimental in nature or use APIs that haven't landed in the SDK's stable channel. They build against master, and aren't (by default) wired into our CI system.

Code reviews

All submissions, including submissions by project members, require review.

This repo is part of the Flutter GitHub account, which means that a lot of folks have the ability to push and merge code. The primary maintainers, though, are:

You are free to add one of these folks (particularly @RedBrogdon) as a reviewer to any PR sent to this repo. We're happy to comment, answer (or ask) questions, and provide feedback.

If you're part of a team that's already landed a sample in the repo (Hi, Material!), and you're updating or fixing that sample, you are not expected to wait on one of the above folks before merging the code. Have it reviewed by someone you trust on your own team, and then merge it.

However, if you're adding a new sample, updating a sample you've never worked on before, or changing something that's a meta-concern like the CI setup, web hosting, project setup, etc., please include one of the primary maintainers as a reviewer.

File headers

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

// Copyright 2020 The Flutter team. All rights reserved.
// Use of this source code is governed by a BSD-style license that can be
// found in the LICENSE file.

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.