|
4 | 4 | Contributing |
5 | 5 | ============ |
6 | 6 |
|
| 7 | +You've discovered a bug or something else you want to change |
| 8 | +in Matplotlib — excellent! |
| 9 | + |
| 10 | +You've worked out a way to fix it — even better! |
| 11 | + |
| 12 | +You want to tell us about it — best of all! |
| 13 | + |
7 | 14 | This project is a community effort, and everyone is welcome to |
8 | 15 | contribute. Everyone within the community |
9 | 16 | is expected to abide by our |
10 | 17 | `code of conduct <https://github.com/matplotlib/matplotlib/blob/main/CODE_OF_CONDUCT.md>`_. |
11 | 18 |
|
12 | | -The project is hosted on |
13 | | -https://github.com/matplotlib/matplotlib |
| 19 | +Below, you can find a number of ways to contribute, and how to connect with the |
| 20 | +Matplotlib community. |
14 | 21 |
|
15 | 22 | Contributor incubator |
16 | 23 | ===================== |
@@ -150,96 +157,8 @@ A brief overview is: |
150 | 157 | Finally, go to the web page of your fork of the Matplotlib repo, and click |
151 | 158 | 'Pull request' to send your changes to the maintainers for review. |
152 | 159 |
|
153 | | -.. seealso:: |
154 | | - |
155 | | - * `Git documentation <https://git-scm.com/doc>`_ |
156 | | - * `Git-Contributing to a Project <https://git-scm.com/book/en/v2/GitHub-Contributing-to-a-Project>`_ |
157 | | - * `Introduction to GitHub <https://lab.github.com/githubtraining/introduction-to-github>`_ |
158 | | - * :ref:`development-workflow` for best practices for Matplotlib |
159 | | - * :ref:`using-git` |
160 | | - |
161 | | -Contributing pull requests |
162 | | --------------------------- |
163 | | - |
164 | | -It is recommended to check that your contribution complies with the following |
165 | | -rules before submitting a pull request: |
166 | | - |
167 | | -* If your pull request addresses an issue, please use the title to describe the |
168 | | - issue and mention the issue number in the pull request description to ensure |
169 | | - that a link is created to the original issue. |
170 | | - |
171 | | -* All public methods should have informative docstrings with sample usage when |
172 | | - appropriate. Use the `numpy docstring standard |
173 | | - <https://numpydoc.readthedocs.io/en/latest/format.html>`_. |
174 | | - |
175 | | -* Formatting should follow the recommendations of PEP8_, as enforced by |
176 | | - flake8_. You can check flake8 compliance from the command line with :: |
177 | | - |
178 | | - python -m pip install flake8 |
179 | | - flake8 /path/to/module.py |
180 | | - |
181 | | - or your editor may provide integration with it. Note that Matplotlib |
182 | | - intentionally does not use the black_ auto-formatter (1__), in particular due |
183 | | - to its unability to understand the semantics of mathematical expressions |
184 | | - (2__, 3__). |
185 | | - |
186 | | - .. _PEP8: https://www.python.org/dev/peps/pep-0008/ |
187 | | - .. _flake8: https://flake8.pycqa.org/ |
188 | | - .. _black: https://black.readthedocs.io/ |
189 | | - .. __: https://github.com/matplotlib/matplotlib/issues/18796 |
190 | | - .. __: https://github.com/psf/black/issues/148 |
191 | | - .. __: https://github.com/psf/black/issues/1984 |
192 | | - |
193 | | -* Each high-level plotting function should have a simple example in the |
194 | | - ``Example`` section of the docstring. This should be as simple as possible |
195 | | - to demonstrate the method. More complex examples should go in the |
196 | | - ``examples`` tree. |
197 | | - |
198 | | -* Changes (both new features and bugfixes) should have good test coverage. See |
199 | | - :ref:`testing` for more details. |
200 | | - |
201 | | -* Import the following modules using the standard scipy conventions:: |
202 | | - |
203 | | - import numpy as np |
204 | | - import numpy.ma as ma |
205 | | - import matplotlib as mpl |
206 | | - import matplotlib.pyplot as plt |
207 | | - import matplotlib.cbook as cbook |
208 | | - import matplotlib.patches as mpatches |
209 | | - |
210 | | - In general, Matplotlib modules should **not** import `.rcParams` using ``from |
211 | | - matplotlib import rcParams``, but rather access it as ``mpl.rcParams``. This |
212 | | - is because some modules are imported very early, before the `.rcParams` |
213 | | - singleton is constructed. |
214 | | - |
215 | | -* If your change is a major new feature, add an entry to the ``What's new`` |
216 | | - section by adding a new file in ``doc/users/next_whats_new`` (see |
217 | | - :file:`doc/users/next_whats_new/README.rst` for more information). |
218 | | - |
219 | | -* If you change the API in a backward-incompatible way, please document it in |
220 | | - :file:`doc/api/next_api_changes/behavior`, by adding a new file with the |
221 | | - naming convention ``99999-ABC.rst`` where the pull request number is followed |
222 | | - by the contributor's initials. (see :file:`doc/api/api_changes.rst` for more |
223 | | - information) |
224 | | - |
225 | | -* See below for additional points about :ref:`keyword-argument-processing`, if |
226 | | - applicable for your pull request. |
227 | | - |
228 | | -.. note:: |
229 | | - |
230 | | - The current state of the Matplotlib code base is not compliant with all |
231 | | - of those guidelines, but we expect that enforcing those constraints on all |
232 | | - new contributions will move the overall code base quality in the right |
233 | | - direction. |
234 | | - |
235 | | - |
236 | | -.. seealso:: |
237 | | - |
238 | | - * :ref:`coding_guidelines` |
239 | | - * :ref:`testing` |
240 | | - * :ref:`documenting-matplotlib` |
241 | | - |
242 | | - |
| 160 | +For more detailed instructions on how to set up Matplotlib for development and |
| 161 | +best practices for contribution, see :ref:`installing_for_devs`. |
243 | 162 |
|
244 | 163 |
|
245 | 164 | .. _contributing_documentation: |
|
0 commit comments