Skip to content
This repository was archived by the owner on Feb 22, 2023. It is now read-only.

Add a PR triage policy to the contributing guide. #1779

Merged
amirh merged 3 commits into from
Jul 8, 2019
Merged

Add a PR triage policy to the contributing guide. #1779

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
5fbe83b
Add a PR triage policy to the contributing guide.
amirh Jun 28, 2019
59253c7
fix grammar
amirh Jun 28, 2019
7b8b7e4
note that the process is experimental
amirh Jun 28, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
37 changes: 25 additions & 12 deletions CONTRIBUTING.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,19 +1,19 @@
Contributing to Flutter Plugins
===============================
# Contributing to Flutter Plugins


[![Build Status](https://api.cirrus-ci.com/github/flutter/plugins.svg)](https://cirrus-ci.com/github/flutter/plugins/master)

_See also: [Flutter's code of conduct](https://flutter.io/design-principles/#code-of-conduct)_

Things you will need
--------------------
## Things you will need


* Linux, Mac OS X, or Windows.
* git (used for source version control).
* An ssh client (used to authenticate with GitHub).

Getting the code and configuring your environment
-------------------------------------------------
## Getting the code and configuring your environment


* Ensure all the dependencies described in the previous section are installed.
* Fork `https://github.com/flutter/plugins` into your own GitHub account. If
Expand All @@ -29,8 +29,8 @@ Getting the code and configuring your environment
fetch from the master repository, not your clone, when running `git fetch`
et al.)

Running the examples
--------------------
## Running the examples


To run an example with a prebuilt binary from the cloud, switch to that
example's directory, run `pub get` to make sure its dependencies have been
Expand All @@ -40,8 +40,7 @@ USB and debugging enabled on that device.
* `cd packages/battery/example`
* `flutter run`

Running the tests
-----------------
## Running the tests

Flutter plugins have both unit tests of their Dart API and integration tests that run on a virtual or actual device.

Expand All @@ -58,8 +57,7 @@ cd example
flutter drive test/<name_of_plugin>.dart
```

Contributing code
-----------------
## Contributing code

We gladly accept contributions via GitHub pull requests.

Expand Down Expand Up @@ -112,3 +110,18 @@ You must complete the
You can do this online, and it only takes a minute.
If you've never submitted code before, you must add your (or your
organization's) name and contact info to the [AUTHORS](AUTHORS) file.

### The review process

Reviewing PRs often requires a non trivial amount of time, as our goal is to use maintainers' time in the most impactful way, we perform prioritization on issues and not on PRs. Issues pertaining to this repository are managed in the [flutter/flutter issue tracker and are labeled with "plugin"](https://github.com/flutter/flutter/issues?q=is%3Aopen+is%3Aissue+label%3Aplugin+sort%3Areactions-%2B1-desc). Non trivial PRs should have an associated issue that will be used for prioritization. See the [prioritization section](https://github.com/flutter/flutter/wiki/Issue-hygiene#prioritization) in the Flutter wiki to understand how issues are prioritized.

@mklim mklim Jun 28, 2019

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: the "as our goal" bit doesn't quite follow. I'm not sure what the named prescriptivist rules are for this, but it's hard to parse and reads almost like a run on. I'd rephrase to break these up into distinct sentences. Something like below (only a suggestion):

Reviewing PRs often requires a non trivial amount of time. We prioritize issues, not PRs, so that we use our maintainers' time in the most impactful way.

@amirh amirh Jun 28, 2019

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks


Newly opened PRs first go through initial triage which results in one of:
* **Merging the PR** - if the PR can be quickly reviewed and looks good.
* **Closing the PR** - if the PR maintainer decides that the PR should not be merged.
* **Moving the PR to the backlog** - if the review requires non trivial effort and the issue isn't a priority; in this case the maintainer will:
* Make sure that the PR has an associated issue labeled with "plugin".
* Add the "backlog" label to the issue.
* Leave a comment on the PR explaining that the review is not trivial and that the issue will be looked at according to priority order.
* **Starting a non trivial review** - if the review requires non trivial effort and the issue is a priority; in this case the maintainer will:
* Add the "in review" label to the issue.
* Self assign the PR.