Skip to content

Commit

Permalink
Deletes outdated references to core committers (#22017)
Browse files Browse the repository at this point in the history
* removes outdated owners-and-committers

* remove ref to core committers

* clarify OWNERS is a subset of the contribution process

* link to contribution process

* change OWNERS reference to proper link

* change to relevant OWNERS link

* minor wording cleanup

* fix case
  • Loading branch information
mrjoro committed Apr 27, 2019
1 parent 0240129 commit 23485bf
Show file tree
Hide file tree
Showing 5 changed files with 14 additions and 49 deletions.
18 changes: 10 additions & 8 deletions contributing/CODE_OWNERSHIP.md
@@ -1,8 +1,10 @@
# Code Ownership and AMP

This document describes the code ownership model for the AMP open source
This document describes the code ownership (OWNERS) model for the AMP open source
project, and in particular the [AMP HTML GitHub project](https://github.com/ampproject/amphtml).

For more information on the overall code contribution process that the OWNERS model is a part of, see the [Contributing code and features](https://github.com/ampproject/amphtml/blob/master/contributing/contributing-code.md) documentation.

The goals of enforcing AMP code ownership are as follows:

* Provide the flexibility to specify a different set of owners for individual
Expand Down Expand Up @@ -64,13 +66,13 @@ described above. Stay tuned for the latest changes.

## Approvals required before merging a change

In order to merge a PR, an approval will be required from at least one of the
owners of each file modified by the PR. See [contributing-code.md](./contributing-code.md)
for more details.
Any change in AMP requires the approval of at least one owner of the code the change
modifies, but this is a subset of the required approvals before a change may be merged.
See the [code contribution process](./contributing-code.md) for more details.

## Criteria for being listed as an owner in an `OWNERS.yaml` file

The `OWNERS.yaml` file for each directory will typically list the creator(s) of
the component or extension it contains, along with those who are most familiar
with the directory contents. See [owners-and-committers.md](./owners-and-committers.md)
for more details.
The `OWNERS.yaml` file for each directory will typically list the creator(s) of
the component or extension it contains, along with those who are most familiar
with the directory contents. To be added to an OWNERS.yaml file create a PR and
go through the normal [code contribution process](./contributing-code.md).
19 changes: 1 addition & 18 deletions contributing/DEVELOPING.md
Expand Up @@ -20,7 +20,7 @@ limitations under the License.

Before you start developing in AMP, check out these resources:
* [CONTRIBUTING.md](../CONTRIBUTING.md) has details on various ways you can contribute to the AMP Project.
* If you're developing in AMP, you should read the [Contributing code](../CONTRIBUTING.md#contributing-code) and [Contributing features](../CONTRIBUTING.md#contributing-features) sections.
* If you're developing in AMP, you should read the [Contributing code and features](./contributing-code.md) documentation, which includes information on code reviews and approvals.
* The [Ongoing participation](../CONTRIBUTING.md#ongoing-participation) section has details on various ways of getting in touch with others in the community including email and Slack.
* **If you are new to open source projects, Git/GitHub, etc.**, check out the [Tips for new open source contributors](../CONTRIBUTING.md#tips-for-new-open-source-contributors) which includes information on getting help and finding your first bug to work on.
* The [Getting Started Quick Start Guide](getting-started-quick.md) has installation steps and basic instructions for [one-time setup](getting-started-quick.md#one-time-setup), how to [build AMP & run a local server](getting-started-quick.md#build-amp--run-a-local-server) and how to [test AMP](getting-started-quick.md#test-amp).
Expand Down Expand Up @@ -87,23 +87,6 @@ In particular, we try to maintain "it might not be perfect but isn't broken"-sup

We also recommend scanning the [spec](../spec/). The non-element part should help understand some of the design aspects.

## Code Reviews

Before any code can be merged into the AMP repository, it has to be reviewed and approved by the [owner and a core committer](https://github.com/ampproject/amphtml/blob/master/contributing/owners-and-committers.md). Note: In the near future, the code ownership model at
[CODE_OWNERSHIP.md](./CODE_OWNERSHIP.md) will be put in place for code reviews.

- If you are contributing a fix or a new feature to AMP, be sure to follow the tips on [preparing your code for review](https://github.com/ampproject/amphtml/blob/master/CONTRIBUTING.md#contributing-code-for-a-feature-coding--implementation-phase) and follow [instructions](https://github.com/ampproject/amphtml/blob/master/contributing/getting-started-e2e.md#send-a-pull-request-ie-request-a-code-review) on how to submit a pull request.

- Pull requests in AMP are triaged similar to Issues and within 2 business days of submitting a PR, someone will be assigned as the reviewer. If you have been working with a core committer or someone else already, @mentioning them in the PR description will be helpful.

- After a reviewer is assigned, expect comments on your code within a few days. Feel free to @mention the reviewer if your PR is high priority or if you don't hear back after 2 business days since opening the PR.

- Turnaround time for a PR to be merged is variable and depends on the size and quality of the code. Most PRs go through multiple cycles of review comments. It can take anywhere between a day for simple fixes to weeks for larger features.

- When you have addressed all the review comments from the reviewer, please be sure to @mention them with a **"All requested changes are done, please take another look"** comment in the PR so they would know PR is ready for the next round.

- If your PR is urgent or not progressing at the pace outlined above, please feel free to ping the [#contributing](https://amphtml.slack.com/messages/contributing) channel on Slack.

## Builds and releases

- The [AMP buildcop](buildcop.md) helps ensure that AMP's builds remain green (i.e. everything builds and all of the tests pass). If you run into issues with builds that seem unrelated to your changes see if the issue is present on [Travis](https://travis-ci.org/ampproject/amphtml/builds) and let the buildcop know.
Expand Down
4 changes: 2 additions & 2 deletions contributing/building-an-amp-extension.md
Expand Up @@ -31,7 +31,7 @@ rating viewer, you'd do this by building an extension.

This document describes how to create a new AMP extension, which is one of the most common ways of adding a new feature to AMP.

Before diving into the details on creating a new AMP extension, please familiarize yourself with the [general process for contributing code and features to AMP](https://github.com/ampproject/amphtml/blob/master/contributing/contributing-code.md). Since you are adding a new extension you will likely need to follow the [process for making a significant change](https://github.com/ampproject/amphtml/blob/master/contributing/contributing-code.md#process-for-significant-changes), including filing an ["Intent to Implement" issue](https://github.com/ampproject/amphtml/labels/INTENT%20TO%20IMPLEMENT) and finding a reviewer before you start significant development.
Before diving into the details on creating a new AMP extension, please familiarize yourself with the [general process for contributing code and features to AMP](https://github.com/ampproject/amphtml/blob/master/contributing/contributing-code.md). Since you are adding a new extension you will likely need to follow the [process for making a significant change](https://github.com/ampproject/amphtml/blob/master/contributing/contributing-code.md#process-for-significant-changes), including filing an ["Intent to Implement" issue](https://github.com/ampproject/amphtml/labels/INTENT%20TO%20IMPLEMENT) and finding a guide before you start significant development.

## Naming

Expand All @@ -57,7 +57,7 @@ The directory structure is below:
├── validator-amp-my-element.protoascii # Validator rules (req'd)
├── amp-my-element.md # Element's main documentation (req'd)
└── More documentation in .md files (optional)
└── OWNERS.yaml # Owners file. Primary contact(s) for the extension. More about owners [here](https://github.com/ampproject/amphtml/blob/master/contributing/owners-and-committers.md) (req'd)
└── OWNERS.yaml # Owners file. Primary contact(s) for the extension. More about owners [here](https://github.com/ampproject/amphtml/blob/master/contributing/CODE_OWNERSHIP.md) (req'd)
```
In most cases you'll only create the required (req'd) files. If your element does not need custom CSS, you don't need to create the CSS file.
Expand Down
2 changes: 1 addition & 1 deletion contributing/creating-a-welcoming-community.md
Expand Up @@ -37,7 +37,7 @@ Here are some ways you can help make the AMP Project even more welcoming. **The
- Let contributors know they can Direct Message you with questions on Slack (if you're comfortable doing so).
- Having conversations about issues/PRs on the issue/PRs themselves is ideal since this provides a more permanent record that may help other contributors. Many contributors are more comfotable asking questions on a less public platform, though, so having these conversations on Slack is fine. (In these cases summarize any clarifications/designs/etc. in the issue/PR after the discussion if it makes sense.)
- Encourage ongoing participation.
- Make sure people who introduce a new component are added to the relevant OWNERS.yaml and let them know about our [OWNERS](https://github.com/ampproject/amphtml/blob/master/contributing/owners-and-committers.md) process. We want contributors to have a sense of ownership over the things they contribute.
- Make sure people who introduce a new component are added to the relevant OWNERS.yaml and let them know about our [OWNERS](https://github.com/ampproject/amphtml/blob/master/contributing/CODE_OWNERSHIP.md) process. We want contributors to have a sense of ownership over the things they contribute.
- Help people who finish a Good First Issue find a new project to tackle and encourage them to take it on. If you don't already have a project in mind, gauge their interests and skill level and work with the rest of the community (or [mrjoro](https://amphtml.slack.com/threads/team/mrjoro)) to find a project suitable for them.
- Some people may only be interested in making one-off fixes (e.g. adding support for their ad network) and that's fine. Even in these cases it doesn't hurt to mention some other ideas for ways to help (e.g. maybe someone adding their ad network wants to make some other more general ads fixes) and let them know we'd love their help.
- Let people know about [design reviews](design-reviews.md).
Expand Down
20 changes: 0 additions & 20 deletions contributing/owners-and-committers.md

This file was deleted.

0 comments on commit 23485bf

Please sign in to comment.