You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Small fixes to documentation and add myself to AUTHORS.
* Rework CONTRIBUTIONS.rst
Use code-blocks instead of literals, change headings for portability and use a relative link to AUTHORS instead of linking to a specific copy.
Every open source project lives from the generous help by contributors that sacrifice their time and ``python-telegram-bot`` is no different. To make participation as pleasant as possible, this project adheres to the `Code of Conduct`_ by the Python Software Foundation.
5
5
6
6
Setting things up
7
-
-----------------
7
+
-------------------
8
8
9
9
1. Fork the ``python-telegram-bot`` repository to your GitHub account.
10
10
11
11
2. Clone your forked repository of ``python-telegram-bot`` to your computer:
If you already know what you'd like to work on, you can skip this section.
34
41
@@ -37,7 +44,7 @@ If you have an idea for something to do, first check if it's already been filed
37
44
Another great way to start contributing is by writing tests. Tests are really important because they help prevent developers from accidentally breaking existing code, allowing them to build cool things faster. If you're interested in helping out, let the development team know by posting to the `developers' mailing list`_, and we'll help you get started.
38
45
39
46
Instructions for making a code change
40
-
-------------------------------------
47
+
####################
41
48
42
49
The central development branch is ``master``, which should be clean and ready for release at any time. In general, all changes should be done as feature branches based off of ``master``.
43
50
@@ -47,13 +54,12 @@ Here's how to make a one-off code change.
47
54
48
55
2. **Create a new branch with this name, starting from** ``master``. In other words, run:
49
56
50
-
``$ git fetch upstream``
51
-
52
-
``$ git checkout master``
53
-
54
-
``$ git merge upstream/master``
57
+
.. code-block:: bash
55
58
56
-
``$ git checkout -b your-branch-name``
59
+
$ git fetch upstream
60
+
$ git checkout master
61
+
$ git merge upstream/master
62
+
$ git checkout -b your-branch-name
57
63
58
64
3. **Make a commit to your feature branch**. Each commit should be self-contained and have a descriptive commit message that helps other developers understand why the changes were made.
59
65
@@ -75,19 +81,27 @@ Here's how to make a one-off code change.
75
81
76
82
- Before making a commit ensure that all automated tests still pass:
77
83
78
-
``$ make test``
84
+
.. code-block::
85
+
86
+
$ make test
79
87
80
88
- To actually make the commit (this will trigger tests for yapf, lint and pep8 automatically):
81
89
82
-
``$ git add your-file-changed.py``
90
+
.. code-block:: bash
91
+
92
+
$ git add your-file-changed.py
93
+
94
+
- yapf may change code formatting, make sure to re-add them to your commit.
83
95
84
-
- yapf may change code formatting, make sure to re-add them to your commit.
96
+
.. code-block:: bash
85
97
86
-
``$ git commit -a -m "your-commit-message-here"``
98
+
$ git commit -a -m "your-commit-message-here"
87
99
88
100
- Finally, push it to your GitHub fork, run:
89
101
90
-
``$ git push origin your-branch-name``
102
+
.. code-block:: bash
103
+
104
+
$ git push origin your-branch-name
91
105
92
106
4. **When your feature is ready to merge, create a pull request.**
93
107
@@ -107,66 +121,67 @@ Here's how to make a one-off code change.
107
121
108
122
- Resolve any merge conflicts that arise. To resolve conflicts between 'your-branch-name' (in your fork) and 'master' (in the ``python-telegram-bot`` repository), run:
109
123
110
-
``$ git checkout your-branch-name``
111
-
112
-
``$ git fetch upstream``
124
+
.. code-block:: bash
113
125
114
-
``$ git merge upstream/master``
115
-
116
-
``$ ...[fix the conflicts]...``
117
-
118
-
``$ ...[make sure the tests pass before committing]...``
119
-
120
-
``$ git commit -a``
121
-
122
-
``$ git push origin your-branch-name``
126
+
$ git checkout your-branch-name
127
+
$ git fetch upstream
128
+
$ git merge upstream/master
129
+
$ ...[fix the conflicts]...
130
+
$ ...[make sure the tests pass before committing]...
131
+
$ git commit -a
132
+
$ git push origin your-branch-name
123
133
124
134
- At the end, the reviewer will merge the pull request.
125
135
126
136
6. **Tidy up!** Delete the feature branch from both your local clone and the GitHub repository:
127
137
128
-
``$ git branch -D your-branch-name``
138
+
.. code-block:: bash
129
139
130
-
``$ git push origin --delete your-branch-name``
140
+
$ git branch -D your-branch-name
141
+
$ git push origin --delete your-branch-name
131
142
132
143
7. **Celebrate.** Congratulations, you have contributed to ``python-telegram-bot``!
133
144
134
145
Style commandments
135
-
==================
146
+
---------------------
136
147
137
148
Specific commandments
138
-
---------------------
149
+
#####################
139
150
140
151
- Avoid using "double quotes" where you can reasonably use 'single quotes'.
141
152
142
153
AssertEqual argument order
143
-
--------------------------
154
+
######################
144
155
145
156
assertEqual method's arguments should be in ('actual', 'expected') order.
146
157
147
158
Properly calling callables
148
-
--------------------------
159
+
#######################
149
160
150
161
Methods, functions and classes can specify optional parameters (with default
151
162
values) using Python's keyword arg syntax. When providing a value to such a
152
-
callable we prefer that the call also uses keyword arg syntax. For example::
163
+
callable we prefer that the call also uses keyword arg syntax. For example:
153
164
154
-
# GOOD
155
-
f(0, optional=True)
165
+
.. code-block:: python
156
166
157
-
# BAD
158
-
f(0, True)
167
+
# GOOD
168
+
f(0, optional=True)
169
+
170
+
# BAD
171
+
f(0, True)
159
172
160
173
This gives us the flexibility to re-order arguments and more importantly
161
174
to add new required arguments. It's also more explicit and easier to read.
162
175
163
176
Properly defining optional arguments
164
-
------------------------------------
177
+
########################
178
+
179
+
It's always good to not initialize optional arguments at class creation,
180
+
instead use ``**kwargs`` to get them. It's well known Telegram API can
181
+
change without notice, in that case if a new argument is added it won't
182
+
break the API classes. For example:
165
183
166
-
It's always good to not initialize optional arguments at class creation,
167
-
instead use ``**kwargs`` to get them. It's well known Telegram API can
168
-
change without notice, in that case if a new argument is added it won't
169
-
break the API classes. For example::
184
+
.. code-block:: python
170
185
171
186
# GOOD
172
187
def__init__(self, id, name, **kwargs):
@@ -183,4 +198,4 @@ break the API classes. For example::
0 commit comments