Skip to content

Commit

Permalink
Browse files Browse the repository at this point in the history
Encourage filing implementation bugs
Also address various nits.
  • Loading branch information
annevk committed Dec 19, 2017
1 parent 540086d commit 0d23ca4
Show file tree
Hide file tree
Showing 3 changed files with 12 additions and 5 deletions.
2 changes: 1 addition & 1 deletion COMMITTING.md
Expand Up @@ -19,7 +19,7 @@ Great commit messages serve at least three important purposes:

As such, you should write a commit message that will allow your future self to understand the intent of change without looking at the diff. This will not only benefit reviewers, but also other maintainers. Your commit message should express intent without delving into implementation details.

For more on this topic, see ["On commit messages"](http://who-t.blogspot.com/2009/12/on-commit-messages.html).
For more on this topic, see ["On commit messages"](https://who-t.blogspot.com/2009/12/on-commit-messages.html).

This comment has been minimized.

Copy link
@snuggs

snuggs Jan 4, 2018

Member

@annevk nice catch. Thanks! :-)


### Structure and conventions

Expand Down
6 changes: 3 additions & 3 deletions CONTRIBUTING.md
Expand Up @@ -8,19 +8,19 @@ See [COMMITTING.md](COMMITTING.md) for further details.

## Pull requests

Leave the **Allow edits from maintainers** option enabled to allow reviewers to fix trivial issues directly on your branch rather than needing to write review comments asking you make the edits. For more details, see [Improving collaboration with forks](https://github.com/blog/2247-improving-collaboration-with-forks) in the GitHub Blog.
Leave the **Allow edits from maintainers** option enabled to allow reviewers to fix trivial issues directly on your branch rather than needing to write review comments asking you make the edits. For more details, see [Improving collaboration with forks](https://github.com/blog/2247-improving-collaboration-with-forks) in the GitHub Blog.

## Tests

For normative changes, a corresponding [web-platform-tests](https://github.com/w3c/web-platform-tests) PR is highly appreciated. The author and reviewer can be different from the PR for the standard. If current behavior is unclear, writing tests first can help inform the discussion. Typically, both PRs will be merged at the same time.
For normative changes, a corresponding [web-platform-tests](https://github.com/w3c/web-platform-tests) pull request (PR) is needed. The author and reviewer can be different from the PR for the standard. If current behavior is unclear, writing tests first can help inform the discussion. Typically, both PRs will be merged at the same time.

To be clear, a test PR with changes that conflict with the standard cannot land before the corresponding standard is changed.

If testing is not practical, please explain why and if appropriate [file an issue](https://github.com/w3c/web-platform-tests/issues/new) to follow up later.

## Investigation

Often in the course of discussing a potential change, spec bug, or browser bug, it's useful to investigate the behavior in question in a variety of rendering engines and provide data back to the discussion. The best way to do this is to host a small test case and report the results in various engines.
Often in the course of discussing a potential change, issue with a standard, or browser bug, it's useful to investigate the behavior in question in a variety of rendering engines and provide data back to the discussion. The best way to do this is to host a small test case and report the results in various engines.

For simple cases (not involving multiple files), sites like [Live DOM Viewer](https://software.hixie.ch/utilities/js/live-dom-viewer/) or [JSBin](https://jsbin.com/) are recommended. For cases involving multiple files, you'll likely need to use your own hosting, for example using [GitHub Pages](https://pages.github.com/). Or you could skip straight to working on web-platform-tests, as discussed above.

Expand Down
9 changes: 8 additions & 1 deletion TEAM.md
Expand Up @@ -4,12 +4,19 @@ These are the general guidelines for maintaining WHATWG standards. Mostly boring

## Handling pull requests

Rules for title/message must be satisfied before pull request is reviewed. See [COMMITTING.md](COMMITTING.md) for further details.
Rules for title/message must be satisfied before pull request (PR) is reviewed. See [COMMITTING.md](COMMITTING.md) for further details.

For normative changes, ask for a [web-platform-tests](https://github.com/w3c/web-platform-tests) PR if testing is practical and not overly burdensome. Aim to merge both PRs at the same time. If one PR is approved but the other needs more work, add the `do not merge yet` label or, in web-platform-tests, the `status:needs-spec-decision` label.

If a follow-up issue is filed in the web-platform-tests repository, add the `type:untestable` or `type:missing-coverage` label, and any other appropriate labels, e.g. `html` for the HTML Standard.

Furthermore, for changes affecting one or more implementations, ensure implementation bugs are filed:

* [Chrome](https://crbug.com/new)
* [Edge](https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/new/)
* [Firefox](https://bugzilla.mozilla.org/enter_bug.cgi?product=Core)
* [Safari](https://bugs.webkit.org/enter_bug.cgi?product=WebKit)

### Checking out pull requests from forks

Pull requests from external contributors come from branches in their forks. You can check out those external branches in order to review and test the commits in those pull requests, and to be able to push changes to them on your own (e.g., fixes for typos)—rather than needing to write review comments asking the PR contributor to make the edits.
Expand Down

0 comments on commit 0d23ca4

Please sign in to comment.