1 |
|
2 | This file is autogenerated based on
|
3 | https://github.com/PolymerElements/ContributionGuide/blob/master/CONTRIBUTING.md
|
4 |
|
5 | If you edit that file, it will get updated everywhere else.
|
6 | If you edit this file, your changes will get overridden :)
|
7 |
|
8 | You can however override the jsbin link with one that's customized to this
|
9 | specific element:
|
10 |
|
11 | jsbin=https://jsbin.com/cagaye/edit?html,output
|
12 | -->
|
13 |
|
14 | # Polymer Elements
|
15 | ## Guide for Contributors
|
16 |
|
17 | Polymer Elements are built in the open, and the Polymer authors eagerly encourage any and all forms of community contribution. When contributing, please follow these guidelines:
|
18 |
|
19 | ### Filing Issues
|
20 |
|
21 | **If you are filing an issue to request a feature**, please provide a clear description of the feature. It can be helpful to describe answers to the following questions:
|
22 |
|
23 | 1. **Who will use the feature?** _“As someone filling out a form…”_
|
24 | 2. **When will they use the feature?** _“When I enter an invalid value…”_
|
25 | 3. **What is the user’s goal?** _“I want to be visually notified that the value needs to be corrected…”_
|
26 |
|
27 | **If you are filing an issue to report a bug**, please provide:
|
28 |
|
29 | 1. **A clear description of the bug and related expectations.** Consider using the following example template for reporting a bug:
|
30 |
|
31 | ```markdown
|
32 | The `paper-foo` element causes the page to turn pink when clicked.
|
33 |
|
34 | ## Expected outcome
|
35 |
|
36 | The page stays the same color.
|
37 |
|
38 | ## Actual outcome
|
39 |
|
40 | The page turns pink.
|
41 |
|
42 | ## Steps to reproduce
|
43 |
|
44 | 1. Put a `paper-foo` element in the page.
|
45 | 2. Open the page in a web browser.
|
46 | 3. Click the `paper-foo` element.
|
47 | ```
|
48 |
|
49 | 2. **A reduced test case that demonstrates the problem.** If possible, please include the test case as a JSBin. Start with this template to easily import and use relevant Polymer Elements: [https://jsbin.com/cagaye/edit?html,output](https://jsbin.com/cagaye/edit?html,output).
|
50 |
|
51 | 3. **A list of browsers where the problem occurs.** This can be skipped if the problem is the same across all browsers.
|
52 |
|
53 | ### Submitting Pull Requests
|
54 |
|
55 | **Before creating a pull request**, please ensure that an issue exists for the corresponding change in the pull request that you intend to make. **If an issue does not exist, please create one per the guidelines above**. The goal is to discuss the design and necessity of the proposed change with Polymer authors and community before diving into a pull request.
|
56 |
|
57 | When submitting pull requests, please provide:
|
58 |
|
59 | 1. **A reference to the corresponding issue** or issues that will be closed by the pull request. Please refer to these issues in the pull request description using the following syntax:
|
60 |
|
61 | ```markdown
|
62 | (For a single issue)
|
63 | Fixes #20
|
64 |
|
65 | (For multiple issues)
|
66 | Fixes #32, fixes #40
|
67 | ```
|
68 |
|
69 | 2. **A succinct description of the design** used to fix any related issues. For example:
|
70 |
|
71 | ```markdown
|
72 | This fixes #20 by removing styles that leaked which would cause the page to turn pink whenever `paper-foo` is clicked.
|
73 | ```
|
74 |
|
75 | 3. **At least one test for each bug fixed or feature added** as part of the pull request. Pull requests that fix bugs or add features without accompanying tests will not be considered.
|
76 |
|
77 | If a proposed change contains multiple commits, please [squash commits](https://www.google.com/url?q=http://blog.steveklabnik.com/posts/2012-11-08-how-to-squash-commits-in-a-github-pull-request) to as few as is necessary to succinctly express the change. A Polymer author can help you squash commits, so don’t be afraid to ask us if you need help with that!
|
78 |
|
\ | No newline at end of file |