|
1 |
| -Contributions to this repository are intended to become part of Recommendation-track documents governed by the |
2 |
| -[W3C Patent Policy](https://www.w3.org/Consortium/Patent-Policy-20040205/) and |
3 |
| -[Software and Document License](https://www.w3.org/Consortium/Legal/copyright-software). To make substantive contributions to specifications, you must either participate |
| 1 | +# Contributor Guidelines |
| 2 | + |
| 3 | +Thank you for your interest in contributing to the [CSS Working Group](https://www.w3.org/Style/CSS/) |
| 4 | +drafts! |
| 5 | + |
| 6 | +Contributions to this repository are intended to become part of Recommendation-track |
| 7 | +documents governed by the: |
| 8 | + |
| 9 | + * [W3C Patent Policy](https://www.w3.org/Consortium/Patent-Policy-20040205/) |
| 10 | + * [Software and Document License](https://www.w3.org/Consortium/Legal/copyright-software) |
| 11 | + |
| 12 | +To make substantive contributions to specifications, you must either participate |
4 | 13 | in the relevant W3C Working Group or make a non-member patent licensing commitment.
|
5 | 14 |
|
6 |
| -If you are not the sole contributor to a contribution (pull request), please identify all |
7 |
| -contributors in the pull request comment. |
| 15 | +## Issue disclosure and discussion |
| 16 | + |
| 17 | +The first step for any contribution, substantive or not, is to either: |
| 18 | + |
| 19 | + 1. [Find an existing issue](https://github.com/w3c/csswg-drafts/issues) directly related to the contribution |
| 20 | + 2. [Add a new issue](https://github.com/w3c/csswg-drafts/issues/new) |
| 21 | + |
| 22 | +Issues are where individual reports and Working Group discussions come together such |
| 23 | +that the eventual consensus can be turned into official specification language. |
8 | 24 |
|
9 |
| -To add a contributor (other than yourself, that's automatic), mark them one per line as follows: |
| 25 | +If you are familiar with a [GitHub-based pull request contribution workflow](https://help.github.com/articles/about-pull-requests/), |
| 26 | +please note that **most issues are subject to quite a bit of discussion** before |
| 27 | +draft language becomes ready for a pull request. Please ensure the full problem |
| 28 | +space of the issue is explored in the discussion, and that consensus has been reached |
| 29 | +by the participating members, before contributing to the |
| 30 | +repository. |
10 | 31 |
|
11 |
| -``` |
12 |
| -+@github_username |
13 |
| -``` |
| 32 | +## Normative and/or substantive contributions |
14 | 33 |
|
15 |
| -If you added a contributor by mistake, you can remove them in a comment with: |
| 34 | +The CSS Working Group operates via the consensus of its membership, and discusses |
| 35 | +all significant matters prior to implementation. |
16 | 36 |
|
17 |
| -``` |
18 |
| --@github_username |
19 |
| -``` |
| 37 | +If adding an new, normative issue, please label/tag the PR as 'Agenda+' to bring |
| 38 | +it to the Working Group's attention. |
20 | 39 |
|
21 |
| -If you are making a pull request on behalf of someone else but you had no part in designing the |
22 |
| -feature, you can remove yourself with the above syntax. |
| 40 | +The Working Group, aside from managing issues on GitHub, mainly discusses specifications |
| 41 | +and requests on [the www-style public mailing list](https://lists.w3.org/Archives/Public/www-style/), |
| 42 | +and in CSSWG meetings. |
23 | 43 |
|
24 |
| -# Tests |
| 44 | +### After discussion |
| 45 | + |
| 46 | +Once the Working Group has come to a consensus, a contributor may file a pull request |
| 47 | +against the issue. The editor of the specification related to the issue will then be |
| 48 | +responsible for reviewing both the content and implementation of the contributed |
| 49 | +changes. |
| 50 | + |
| 51 | +Please follow the [Pull Request template](https://github.com/w3c/csswg-drafts/blob/master/.github/PULL_REQUEST_TEMPLATE.md) |
| 52 | +when contributing to the repository. |
| 53 | + |
| 54 | +### Tests |
25 | 55 |
|
26 | 56 | For normative changes for any specification in
|
27 | 57 | [CR or later](https://www.w3.org/Style/CSS/current-work) as well as the pre-CR specifications listed
|
28 | 58 | below, a corresponding [web-platform-tests](https://github.com/web-platform-tests/wpt) PR must be
|
29 | 59 | provided, except if testing is not practical; for other specifications it is usually appreciated.
|
| 60 | + |
30 | 61 | Typically, both PRs will be merged at the same time. Note that a test change that contradicts the
|
31 | 62 | spec should not be merged before the corresponding spec change. If testing is not practical, please
|
32 | 63 | explain why and if appropriate [file an issue](https://github.com/web-platform-tests/wpt/issues/new)
|
33 | 64 | to follow up later. Add the `type:untestable` or `type:missing-coverage` label as appropriate.
|
34 | 65 |
|
35 | 66 | The pre-CR specifications with this testing requirement are currently:
|
36 | 67 |
|
37 |
| -* cssom |
38 |
| -* cssom-view |
| 68 | + * cssom |
| 69 | + * cssom-view |
| 70 | + |
| 71 | +## Non-substantive contributions |
| 72 | + |
| 73 | +For simple spelling, grammar, or markup fixes unrelated to the substance of a specification, |
| 74 | +please file an issue with the usual shortname tagging (ie. `[css-foo]`) for the spec(s) |
| 75 | +edited by the change. You may then issue a pull request referencing the issue number. |
0 commit comments