Thanks to visit codestin.com
Credit goes to github.com

Skip to content

DOC : whole bunch of documentation clean up #3170

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 20 commits into from
Closed
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
DOC : re-worked patch/bug report FAQ
  • Loading branch information
tacaswell committed Jul 18, 2014
commit 5f60a1e75b031ab6b2de3a60913b134cd10504b8
55 changes: 24 additions & 31 deletions doc/faq/howto_faq.rst
Original file line number Diff line number Diff line change
Expand Up @@ -482,36 +482,28 @@ Contributing: howto

.. _how-to-submit-patch:

Submit a patch
--------------

See :ref:`making-patches` for information on how to make a patch with git.

If you are posting a patch to fix a code bug, please explain your
patch in words -- what was broken before and how you fixed it. Also,
even if your patch is particularly simple, just a few lines or a
single function replacement, we encourage people to submit git diffs
against HEAD of the branch they are patching. It just makes life
easier for us, since we (fortunately) get a lot of contributions, and
want to receive them in a standard format. If possible, for any
non-trivial change, please include a complete, free-standing example
that the developers can run unmodified which shows the undesired
behavior pre-patch and the desired behavior post-patch, with a clear
verbal description of what to look for. A developer may
have written the function you are working on years ago, and may no
longer be with the project, so it is quite possible you are the world
expert on the code you are patching and we want to hear as much detail
as you can offer.

When emailing your patch and examples, feel free to paste any code
into the text of the message, indeed we encourage it, but also attach
the patches and examples since many email clients screw up the
formatting of plain text, and we spend lots of needless time trying to
reformat the code to make it usable.

You should check out the guide to developing matplotlib to make sure
your patch abides by our coding conventions
:ref:`developers-guide-index`.
Reporting a bug or submitting a patch
-------------------------------------

The development of matplotlib is organized through `github
<https://github.com/matplotlib/matplotlib>`_. If you would like
to report a bug or submit a patch please use that interface.

To report a bug (or request a feature) just `create an issue
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've never been a huge fan of using the issue tracker for feature requests, but I also don't really have a better idea (other than perhaps maintaining a second repo which is for feature-request issues only).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is the most easily accessible tool for keeping track of/discussing changes to the code. It is unweildy to have many (very) old issues around. We should probably be better about closing things we really aren't going to implement. Maybe we should ask people to mail feature requests to the mailing list which get converted to issues when there is consensus they should be done (or some one just starts doing it).

When all you have is an issue tracker everthing looks like an issue....

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To reinforce and extend this idea: I'm afraid there is a trend for people to go straight to the tracker with problems--not just feature requests--that really should be presented first on the list, so that a wider audience has a chance to answer questions.

<https://github.com/matplotlib/matplotlib/issues/new>`_ on github.
Please include a `Short, Self Contained, Correct (Compilable), Example
<http://sscce.org>`_ demonstrating what is wrong. This makes it much
easier for the developers to evaluate the bug report and gives them a
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is that sentence grammatically correct?

start on where to start looking for the bug. The easier it is for the
developers to understand your problem the faster it will get fixed.
Expect that the bug reports will be a conversation. If you do not
want to register with github, please email bug reports to `the mailing
list <[email protected]>`_.


The easiest way to submit patches to matplotlib is through pull
requests on github. Please see the :ref:`developers-guide-index` for
the details.


.. _how-to-contribute-docs:
Expand Down Expand Up @@ -558,7 +550,8 @@ your documents.
Once your documentation contributions are working (and hopefully
tested by actually *building* the docs) you can submit them as a patch
against git. See :ref:`install-git` and :ref:`how-to-submit-patch`.
Looking for something to do? Search for `TODO <../search.html?q=todo>`_.
Looking for something to do? Search for `TODO <../search.html?q=todo>`_
or look at the open issues on github.



Expand Down