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