Updating CONTRIBUTING.md with repo conventions and review guide. (#199)

pull/207/head
Andrew Brogdon 5 years ago committed by GitHub
parent 8d4c30a782
commit d62b7b88b2
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

@ -20,7 +20,7 @@ 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 anything you see here. You can let us know on the
[FlutterDev Google Group](https://groups.google.com/forum/#!forum/flutter-dev) [FlutterDev Google Group](https://groups.google.com/forum/#!forum/flutter-dev)
when you've published something and Tweet about it with the when you've published something and Tweet about it with the
[#flutterio](https://twitter.com/search?q=%23flutterio) hashtag. [#FlutterDev](https://twitter.com/search?q=%23FlutterDev) hashtag.
## So what should be contributed here, then? ## So what should be contributed here, then?
@ -43,17 +43,79 @@ 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 possibly guide you. Coordinating up front makes it much easier to avoid
frustration later on. 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](https://github.com/flutter/flutter/wiki/Flutter-build-release-channels)
release of the Flutter SDK.
* Include the same
[`analysis_options.yaml`](https://github.com/flutter/samples/blob/master/gallery/gallery/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](travis_script.sh), 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](https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo)
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 ## Code reviews
All submissions, including submissions by project members, require review. All submissions, including submissions by project members, require review.
This repo is part of the [Flutter](https://github.com/flutter) GitHub account,
which means that a lot of folks have the ability to push and merge code. The
primary maintainers, though, are:
* [@RedBrogdon](https://github.com/RedBrogdon)
* [@johnpryan](https://github.com/johnpryan)
* [@domesticmouse](https://github.com/domesticmouse)
* [@theacodes](https://github.com/theacodes)
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 ## File headers
All files in the project must start with the following header. All files in the project must start with the following header.
// Copyright 2018 The Chromium Authors. All rights reserved. ```
// Use of this source code is governed by a BSD-style license that can be // Copyright 2020 The Flutter team. All rights reserved.
// found in the LICENSE file. // Use of this source code is governed by a BSD-style license that can be
// found in the LICENSE file.
```
## The small print ## The small print

Loading…
Cancel
Save