-
Notifications
You must be signed in to change notification settings - Fork 12
/
Copy pathCONTRIBUTING
108 lines (70 loc) · 3.74 KB
/
CONTRIBUTING
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
The project is open source and if you like you can help. Here are some contribution guidelines:
* we use the Apache 2.0 licence
* we recommend to use pycharm for editing and utlize the `Inspect
Code` feature regularly on the files you modify and fix the sensible
pep8 warnings. Look at other warnings and errors
* we disallow editing with notepad
* use ``.format`` instead of ``%`` in print statements
* use ``from __future__ import print_function`` at the beginning of the file and use
``print("msg")`` instead of ``print msg``
* use ``class name(object):`` and not just ``class name:``
* use ``Console.error`` when printing errors if you develop a command
for the commandline
* use ``Console.ok`` when printing something that confirms the action
is ok. In many cases you may not want o use print, but
Console.ok. Please note that Console.ok, takesa string argument.
* use ``ConfigDict`` when reading yaml files. It even allows you to
read a yaml file in order, make changes to it and write it back
* use nosetests and pytest for testing your programs
An example is provided in ``tests/test_sample.py``::
nosetests -v --nocapture tests/test_sample.py
py.test tests/test_sample.py
you can copy this to ``tests/test_yourfile.py`` and then replace in
that file the occurrence of ``_sample`` with ``_yourfile``
make sure to create meaningful tests.
* use RST to write documentation http://sphinx-doc.org/rest.html
* do not include fancy self tests in the documentation, instead write
nosetests
* we are using https://pypi.python.org/pypi/gitchangelog for creating
changelogs automatically. Thus you need to use a prefix in any
commit. It includes the type and the user for which the commit is
relevant. Examples are::
chg: usr: simple changes relevant for users (spelling, ...)
fix: usr: major changes for users
new: usr: new feature for users
chg: dev: simple changes relevant for developers (spelling, ...)
fix: dev: major changes for developers
new: dev: new feature for developers
* use as much python 3 like code but use python 2 for development to also make the
code portable on python 2
* look at http://python-future.org/compatible_idioms.html for tips to
make python 2 look more like python 3. Be careful with dicts to
make them not inefficient.
* iteritems::
import six
d = dict( foo=1, bar=2 )
for k, v in six.iteritems(d):
print(k, v)
PRIORITIZATON
-------------
Prioritizations of tasks can be established while using the first
line of an issue body. Here you can use a tag such as::
P:1
Where the number behind p identifies the priority. As normal github
does not support priority tasks, They can be printed from cloudmesh
dev branch, if you use the command:
bin/git-priority,py
We will enhance the tools to print priority lists gradually as needed.
an output will look like:
+------+------+----------------------+------------+------------+----------------------+
| P | N | title | assignee | milestone | labels |
+------+------+----------------------+------------+------------+----------------------+
| 1 | 202 | cm refresh on/off | gregor | 2016/03/31 | bug, Gregor |
+------+------+----------------------+------------+------------+----------------------+
| 999 | 201 | cm cluster | fugang | priority | Fugang |
+------+------+----------------------+------------+------------+----------------------+
which easily renders in MD. If you are only interested in a particular milestone, you
can fgrep for it::
bin/git-priority,py | fgrep priority
An example for sorting and selection is::
bin/git-priority.py | sort -t "|" -k 1 | fgrep priority