forked from cookiecutter/cookiecutter
-
Notifications
You must be signed in to change notification settings - Fork 0
/
CONTRIBUTING.rst
458 lines (298 loc) · 14.4 KB
/
CONTRIBUTING.rst
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
============
Contributing
============
Contributions are welcome, and they are greatly appreciated! Every
little bit helps, and credit will always be given.
.. toctree::
:numbered:
:maxdepth: 2
types_of_contributions
contributor_setup
contributor_guidelines
contributor_testing
core_committer_guide
Types of Contributions
----------------------
You can contribute in many ways:
Create Cookiecutter Templates
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Some other Cookiecutter templates to list in the :ref:`README <readme>` would
be great.
If you create a Cookiecutter template, submit a pull request adding it to
README.rst.
Report Bugs
~~~~~~~~~~~
Report bugs at https://github.com/audreyr/cookiecutter/issues.
If you are reporting a bug, please include:
* Your operating system name and version.
* Any details about your local setup that might be helpful in troubleshooting.
* If you can, provide detailed steps to reproduce the bug.
* If you don't have steps to reproduce the bug, just note your observations in
as much detail as you can. Questions to start a discussion about the issue
are welcome.
Fix Bugs
~~~~~~~~
Look through the GitHub issues for bugs. Anything tagged with "bug"
is open to whoever wants to implement it.
Implement Features
~~~~~~~~~~~~~~~~~~
Look through the GitHub issues for features. Anything tagged with "enhancement"
and "please-help" is open to whoever wants to implement it.
Please do not combine multiple feature enhancements into a single pull request.
Note: this project is very conservative, so new features that aren't tagged
with "please-help" might not get into core. We're trying to keep the code base
small, extensible, and streamlined. Whenever possible, it's best to try and
implement feature ideas as separate projects outside of the core codebase.
Write Documentation
~~~~~~~~~~~~~~~~~~~
Cookiecutter could always use more documentation, whether as part of the
official Cookiecutter docs, in docstrings, or even on the web in blog posts,
articles, and such.
If you want to review your changes on the documentation locally, you can do::
pip install -r docs/requirements.txt
make servedocs
This will compile the documentation, open it in your browser and start
watching the files for changes, recompiling as you save.
Submit Feedback
~~~~~~~~~~~~~~~
The best way to send feedback is to file an issue at
https://github.com/audreyr/cookiecutter/issues.
If you are proposing a feature:
* Explain in detail how it would work.
* Keep the scope as narrow as possible, to make it easier to implement.
* Remember that this is a volunteer-driven project, and that contributions
are welcome :)
Setting Up the Code for Local Development
-----------------------------------------
Here's how to set up `cookiecutter` for local development.
1. Fork the `cookiecutter` repo on GitHub.
2. Clone your fork locally::
$ git clone [email protected]:your_name_here/cookiecutter.git
3. Install your local copy into a virtualenv. Assuming you have virtualenvwrapper installed, this is how you set up your fork for local development::
$ mkvirtualenv cookiecutter
$ cd cookiecutter/
$ python setup.py develop
4. Create a branch for local development::
$ git checkout -b name-of-your-bugfix-or-feature
Now you can make your changes locally.
5. When you're done making changes, check that your changes pass the tests and flake8::
$ pip install tox
$ tox
Please note that tox runs flake8 automatically, since we have a test environment for it.
If you feel like running only the flake8 environment, please use the following command::
$ tox -e flake8
6. Commit your changes and push your branch to GitHub::
$ git add .
$ git commit -m "Your detailed description of your changes."
$ git push origin name-of-your-bugfix-or-feature
7. Check that the test coverage hasn't dropped::
$ tox -e cov-report
8. Submit a pull request through the GitHub website.
Contributor Guidelines
----------------------
Pull Request Guidelines
~~~~~~~~~~~~~~~~~~~~~~~
Before you submit a pull request, check that it meets these guidelines:
1. The pull request should include tests.
2. If the pull request adds functionality, the docs should be updated. Put
your new functionality into a function with a docstring, and add the
feature to the list in README.rst.
3. The pull request should work for Python 2.7, 3.4, 3.5, 3.6, and PyPy on
AppVeyor and Travis CI.
4. Check https://travis-ci.org/audreyr/cookiecutter/pull_requests and
https://ci.appveyor.com/project/audreyr/cookiecutter/history to ensure the tests pass for all supported Python versions and platforms.
Coding Standards
~~~~~~~~~~~~~~~~
* PEP8
* Functions over classes except in tests
* Quotes via http://stackoverflow.com/a/56190/5549
* Use double quotes around strings that are used for interpolation or that are natural language messages
* Use single quotes for small symbol-like strings (but break the rules if the strings contain quotes)
* Use triple double quotes for docstrings and raw string literals for regular expressions even if they aren't needed.
* Example:
.. code-block:: python
LIGHT_MESSAGES = {
'English': "There are %(number_of_lights)s lights.",
'Pirate': "Arr! Thar be %(number_of_lights)s lights."
}
def lights_message(language, number_of_lights):
"""Return a language-appropriate string reporting the light count."""
return LIGHT_MESSAGES[language] % locals()
def is_pirate(message):
"""Return True if the given message sounds piratical."""
return re.search(r"(?i)(arr|avast|yohoho)!", message) is not None
* Write new code in Python 3.
Testing with tox
----------------
Tox uses py.test under the hood, hence it supports the same syntax for selecting tests.
For further information please consult the `pytest usage docs`_.
To run a particular test class with tox::
$ tox -e py '-k TestFindHooks'
To run some tests with names matching a string expression::
$ tox -e py '-k generate'
Will run all tests matching "generate", test_generate_files for example.
To run just one method::
$ tox -e py '-k "TestFindHooks and test_find_hook"'
To run all tests using various versions of python in virtualenvs defined in tox.ini, just run tox.::
$ tox
This configuration file setup the pytest-cov plugin and it is an additional
dependency. It generate a coverage report after the tests.
It is possible to tests with some versions of python, to do this the command
is::
$ tox -e py27,py34,pypy
Will run py.test with the python2.7, python3.4 and pypy interpreters, for
example.
Core Committer Guide
====================
Vision and Scope
----------------
Core committers, use this section to:
* Guide your instinct and decisions as a core committer
* Limit the codebase from growing infinitely
Command-Line Accessible
~~~~~~~~~~~~~~~~~~~~~~~
* Provides a command-line utility that creates projects from cookiecutters
* Extremely easy to use without having to think too hard
* Flexible for more complex use via optional arguments
API Accessible
~~~~~~~~~~~~~~
* Entirely function-based and stateless (Class-free by intentional design)
* Usable in pieces for developers of template generation tools
Being Jinja2-specific
~~~~~~~~~~~~~~~~~~~~~
* Sets a standard baseline for project template creators, facilitating reuse
* Minimizes the learning curve for those who already use Flask or Django
* Minimizes scope of Cookiecutter codebase
Extensible
~~~~~~~~~~
Being extendable by people with different ideas for Jinja2-based project template tools.
* Entirely function-based
* Aim for statelessness
* Lets anyone write more opinionated tools
Freedom for Cookiecutter users to build and extend.
* No officially-maintained cookiecutter templates, only ones by individuals
* Commercial project-friendly licensing, allowing for private cookiecutters and private Cookiecutter-based tools
Fast and Focused
~~~~~~~~~~~~~~~~
Cookiecutter is designed to do one thing, and do that one thing very well.
* Cover the use cases that the core committers need, and as little as possible beyond that :)
* Generates project templates from the command-line or API, nothing more
* Minimize internal line of code (LOC) count
* Ultra-fast project generation for high performance downstream tools
Inclusive
~~~~~~~~~
* Cross-platform and cross-version support are more important than features/functionality
* Fixing Windows bugs even if it's a pain, to allow for use by more beginner coders
Stable
~~~~~~
* Aim for 100% test coverage and covering corner cases
* No pull requests will be accepted that drop test coverage on any platform, including Windows
* Conservative decisions patterned after CPython's conservative decisions with stability in mind
* Stable APIs that tool builders can rely on
* New features require a +1 from 3 core committers
VCS-Hosted Templates
~~~~~~~~~~~~~~~~~~~~
Cookiecutter project templates are intentionally hosted VCS repos as-is.
* They are easily forkable
* It's easy for users to browse forks and files
* They are searchable via standard Github/Bitbucket/other search interface
* Minimizes the need for packaging-related cruft files
* Easy to create a public project template and host it for free
* Easy to collaborate
Process: Pull Requests
----------------------
If a pull request is untriaged:
* Look at the roadmap
* Set it for the milestone where it makes the most sense
* Add it to the roadmap
How to prioritize pull requests, from most to least important:
#. Fixes for broken tests. Broken means broken on any supported platform or Python version.
#. Extra tests to cover corner cases.
#. Minor edits to docs.
#. Bug fixes.
#. Major edits to docs.
#. Features.
Ensure that each pull request meets all requirements in this checklist:
https://gist.github.com/audreyr/4feef90445b9680475f2
Process: Issues
---------------
If an issue is a bug that needs an urgent fix, mark it for the next patch release.
Then either fix it or mark as please-help.
For other issues: encourage friendly discussion, moderate debate, offer your thoughts.
New features require a +1 from 2 other core committers (besides yourself).
Process: Roadmap
----------------
The roadmap is https://github.com/audreyr/cookiecutter/milestones?direction=desc&sort=due_date&state=open
Due dates are flexible. Core committers can change them as needed. Note that GitHub sort on them is buggy.
How to number milestones:
* Follow semantic versioning. See http://semver.org
Milestone size:
* If a milestone contains too much, move some to the next milestone.
* Err on the side of more frequent patch releases.
Process: Pull Request merging and HISTORY.rst maintenance
---------------------------------------------------------
If you merge a pull request, you're responsible for updating `AUTHORS.rst` and `HISTORY.rst`
When you're processing the first change after a release, create boilerplate following the existing pattern:
.. code-block:: rest
x.y.z (Development)
~~~~~~~~~~~~~~~~~~~
The goals of this release are TODO: release summary of features
Features:
* Feature description, thanks to @contributor (#PR).
Bug Fixes:
* Bug fix description, thanks to @contributor (#PR).
Other changes:
* Description of the change, thanks to @contributor (#PR).
.. _`@contributor`: https://github.com/contributor
Process: Accepting Template Pull Requests
-----------------------------------------
#. Run the template to generate the project.
#. Attempt to start/use the rendered project.
#. Merge the template in.
#. Update the history file.
.. note:: Adding a template doesn't give authors credit.
Process: Generating CONTRIBUTING.rst
-------------------------------------
From the `cookiecutter` project root::
$ make contributing
This will generate the following message::
rm CONTRIBUTING.rst
touch CONTRIBUTING.rst
cat docs/contributing.rst >> CONTRIBUTING.rst
echo "\n\n" >> CONTRIBUTING.rst
cat docs/types_of_contributions.rst >> CONTRIBUTING.rst
echo "\n\n" >> CONTRIBUTING.rst
cat docs/contributor_setup.rst >> CONTRIBUTING.rst
echo "\n\n" >> CONTRIBUTING.rst
cat docs/contributor_guidelines.rst >> CONTRIBUTING.rst
echo "\n\n" >> CONTRIBUTING.rst
cat docs/contributor_testing.rst >> CONTRIBUTING.rst
echo "\n\n" >> CONTRIBUTING.rst
cat docs/core_committer_guide.rst >> CONTRIBUTING.rst
echo "\n\nAutogenerated from the docs via \`make contributing\`" >> CONTRIBUTING.rst
echo "WARNING: Don't forget to replace any :ref: statements with literal names"
WARNING: Don't forget to replace any :ref: statements with literal names
Process: Your own code changes
------------------------------
All code changes, regardless of who does them, need to be reviewed and merged by someone else.
This rule applies to all the core committers.
Exceptions:
* Minor corrections and fixes to pull requests submitted by others.
* While making a formal release, the release manager can make necessary, appropriate changes.
* Small documentation changes that reinforce existing subject matter. Most commonly being, but not limited to spelling and grammar corrections.
Responsibilities
----------------
#. Ensure cross-platform compatibility for every change that's accepted. Windows, Mac, Debian & Ubuntu Linux.
#. Ensure that code that goes into core meets all requirements in this checklist: https://gist.github.com/audreyr/4feef90445b9680475f2
#. Create issues for any major changes and enhancements that you wish to make. Discuss things transparently and get community feedback.
#. Don't add any classes to the codebase unless absolutely needed. Err on the side of using functions.
#. Keep feature versions as small as possible, preferably one new feature per version.
#. Be welcoming to newcomers and encourage diverse new contributors from all backgrounds. See the Python Community Code of Conduct (https://www.python.org/psf/codeofconduct/).
Becoming a Core Committer
-------------------------
Contributors may be given core commit privileges. Preference will be given to those with:
A. Past contributions to Cookiecutter and other open-source projects. Contributions to Cookiecutter include both code (both accepted and pending) and friendly participation in the issue tracker. Quantity and quality are considered.
B. A coding style that the other core committers find simple, minimal, and clean.
C. Access to resources for cross-platform development and testing.
D. Time to devote to the project regularly.
Autogenerated from the docs via `make contributing`