Conversation
|
Would be good if someone could double check |
| non-descriptive titles such as "Addresses issue #8576".--> | ||
|
|
||
| <!--If you are contributing fixes to docstrings | ||
| (which are very welcome!), please pay attention to |
There was a problem hiding this comment.
Can we make this less passive aggressive?
There was a problem hiding this comment.
Feel free to propose an alternate wording 😃
There was a problem hiding this comment.
I'm worried that the template is getting too large for anyone to bother reading - I'm happy to just get rid of (which are very welcome!) here,
|
Temporarily closed to let #9513 be merged first. |
4d27a68 to
83fb034
Compare
dstansby
left a comment
There was a problem hiding this comment.
A couple of minor things, otherwise looks good to me!
| 6. pillow | ||
| 7. graphviz | ||
| 6. Pillow | ||
| 7. Graphviz |
| exist in the root directory. These contain Python files that are built by `Sphinx Gallery`_. | ||
| When the docs are built, directories of the same name will be generated inside of :file:`docs/`. | ||
| The generated directories :file:`docs/gallery` and :file:`docs/tutorials` can be safely deleted. | ||
| An exception to this are the directories :file:`gallery` and |
There was a problem hiding this comment.
Should be examples instead of gallery I think now?
There was a problem hiding this comment.
No, the files end up in the gallery subfolder of the source tree (and the build).
| :file:`tutorials`, which exist in the root directory. These contain Python | ||
| files that are built by `Sphinx Gallery`_. When the docs are built, | ||
| directories of the same name will be generated inside of :file:`docs/`. The | ||
| generated directories :file:`docs/gallery` and :file:`docs/tutorials` can be |
There was a problem hiding this comment.
examples instead of gallery again here
| non-descriptive titles such as "Addresses issue #8576".--> | ||
|
|
||
| <!--If you are contributing fixes to docstrings | ||
| (which are very welcome!), please pay attention to |
There was a problem hiding this comment.
I'm worried that the template is getting too large for anyone to bother reading - I'm happy to just get rid of (which are very welcome!) here,
Update PULL_REQUEST_TEMPLATE.md to emphasize markup specificities in RST (as opposed to md) regarding double/single backquotes and asterisks. In documenting_mpl.rst: - Various reformattings/line wrappings/rewordings. - Explicitly mark the highlighting language of each code block, as we have a mix of python/shell/rst (and emacs lisp). - Drop unneeded `:func:`/`:class:` markups. - Drop request to line wrap docstrings at 70 characters (in practice they are line-wrapped at 79 like normal Python sources). - Do not forbid spanned cells in tables, which recent Sphinxes handles just fine. In make.py: - Simplify argument parsing, slightly improving output of `./make.py --help`
83fb034 to
37438af
Compare
|
Removed the 'very welcome'. |
|
This looks fine to me. I was disappointed to still not see a description of how to reference functions both in MPL and using inter-sphinx. This is badly needed in my opinion. @dstansby does your PR address this? |
|
It doesn't yet, but it can! |
|
There seem to be a conflict, please backport manually |
|
re-milestoning this to 2.2. There is at least one other PR that did not get backported previously, the backport is not clean at all. |
Update PULL_REQUEST_TEMPLATE.md to emphasize markup specificities in RST
(as opposed to md) regarding double/single backquotes and asterisks.
(I'm a bit tired of pointing to this every other docstring PR.)
In documenting_mpl.rst:
have a mix of python/shell/rst (and emacs lisp).
:func:/:class:markups.they are line-wrapped at 79 like normal Python sources).
just fine.
In make.py:
./make.py --helpPR Summary
PR Checklist