#2319 Add pull request template, w3c cepc, and shift some text around #2320
Conversation
CODE_OF_CONDUCT.md
Outdated
| # W3C Code of Ethics and Professional Conduct | ||
|
|
||
| (Originally [published at w3.org](https://www.w3.org/Consortium/cepc/)) | ||
|
|
There was a problem hiding this comment.
Should we duplicate the W3C code of conduct, or merely link to it? Duplicating means we might get out of sync if upstream is updated.
There was a problem hiding this comment.
That's a good question!
Linking
Pro
- Less maintenance concern
Con
- Requires more clicks to get to content
- W3C site experience different than GitHub/repo experience
- Potential to have slightly off-putting message
Including
Pro
- Easy for new contributors to access the content
- No need for context-switching
Con
- Need to periodically update the content as the CEPC changes
Given that the CEPC hasn't been updated in nearly 3 years, it's probably safe to include it as markdown and update it the next time there's an edit.
There was a problem hiding this comment.
I mean, we could easily just have a less off-putting message than that example does. :) I'm mostly in favor of linking, fwiw.
.github/PULL_REQUEST_TEMPLATE
Outdated
|
|
||
| **Before submitting a pull request,** please make sure the following is done: | ||
|
|
||
| 1. Fork [the repository](https://github.com/w3c/csswg-drafts) and create your branch from `master`. |
There was a problem hiding this comment.
First step is, if there isn't an issue and it isn't a very simple fix like markup, spelling, or grammar error fixes, file an issue for discussion.
While in some cases specific wording changes are useful to review, in many cases it makes more sense to get agreement on the nature of the changes required before crafting specific wording. Either way, discussions on significant changes need to involve more than just the patch author and the reviewer, as the CSSWG operates by consensus and this requires broader participation in discussions than a typical software bugfix. So getting bogged down in the review workflow over specific wording is usually not the right first step to a significant change.
.github/PULL_REQUEST_TEMPLATE
Outdated
| 2. Refer to the [Contributor guidelines](https://github.com/w3c/csswg-drafts/blob/master/CONTRIBUTING.md) about any necessary test PRs | ||
| 3. Add attribution for additional contributors (see section below) | ||
| 4. Refer (`@`-tag) to the specification's editor, if known | ||
| 5. For early-stage specs, label/tag the PR as 'Agenda+' to bring it to the WG's attention |
There was a problem hiding this comment.
Not sure why early-stage specs need anything different here.
|
@fantasai Thank you for reviewing! Your feedback was helpful for me to better understand your Working Group's contribution flow, and to amend the PR in what I believe is a commonsense way.
Of course @frivoal is right about linking to the CPEC instead of including it verbatim. I kept the text of the CODE_OF_CONDUCT.md as simple as possible. If anybody ever needs a markdown version of the CPEC, it will live in memory as an intermediate commit of this PR 😄 As someone who has never participated in any W3C or other spec work before #2319 , I may have come into some "dogfooding" insights that might be of some value specifically for this sort of documentation. That information I'll put separately in the thread for the aforementioned issue. Thanks again! |
|
|
||
| For simple spelling, grammar, or markup fixes unrelated to the substance of a specification, | ||
| please file an issue with the usual shortname tagging (ie. `[css-foo]`) for the spec(s) | ||
| edited by the change. You may then issue a pull request referencing the issue number. |
There was a problem hiding this comment.
As I think I mentioned, simple fixes like this can just get a PR without an issue being filed (although if there is one, the PR should attempt to close it).
|
|
||
| If you added a contributor by mistake, you can remove them in a comment with: | ||
| The CSS Working Group operates via the consensus of its membership, and discusses | ||
| all significant matters prior to implementation. |
There was a problem hiding this comment.
This paragraph seem redundant with the previous one?
| -@github_username | ||
| ``` | ||
| If adding an new, normative issue, please label/tag the PR as 'Agenda+' to bring | ||
| it to the Working Group's attention. |
There was a problem hiding this comment.
Unfortunately, GitHub's access control makes labels inaccessible except to members. :( We'll have to leave this paragraph out. Or note that issues are regularly (but sometimes infrequently) triaged by the WG members responsible for the relevant area of CSS.
|
Not sure how to edit pull requests, so just gonna merge this in and fix later. |
|
Followed up with d478f2b |
As mentioned in the issue description #2319 , this PR moves some text around, makes a new template for PRs, and includes the W3C CEPC directly in the repo for ease of reference by first-time contributors.
I realize the untestable irony in including a pull request template in a pull request... but it's a start?