|
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