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

Skip to content

Commit ed86a39

Browse files
story645timhoffmesibingamelissawmefiring
committed
content guidelines
Co-authored-by: Tim Hoffmann <[email protected]> Co-authored-by: Eva Sibinga <[email protected]> Co-authored-by: melissawm <[email protected]> Co-authored-by: Eric Firing <[email protected]> Co-authored-by: Thomas A Caswell <[email protected]> Co-authored-by: Jody Klymak <[email protected]>
1 parent d2cc4d0 commit ed86a39

File tree

8 files changed

+482
-33
lines changed

8 files changed

+482
-33
lines changed

doc/devel/content_guide/api.rst

Lines changed: 11 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,11 @@
1+
.. _content-api:
2+
3+
API reference
4+
=============
5+
6+
The API reference documentation describes the library interfaces, e.g. inputs, outputs,
7+
and expected behavior. See :ref:`writing-docstrings` for guidance on writing docstrings.
8+
9+
The pages in :file:`doc/api` are purely technical definitions of layout; therefore new
10+
API reference documentation should be added to the module docstrings. This placement
11+
keeps all API reference documentation about a module in the same file.

doc/devel/content_guide/examples.rst

Lines changed: 33 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,33 @@
1+
.. _content-examples:
2+
3+
Examples gallery
4+
================
5+
6+
The gallery of examples contains visual demonstrations of Matplotlib features. Gallery
7+
examples exist so that readers can scan through visual examples. Unlike tutorials or
8+
user guides, gallery examples teach by demonstration, rather than by instruction or
9+
explanation.
10+
11+
Gallery examples should avoid instruction or excessive explanation except for brief
12+
clarifying code comments. Instead, they can tag related concepts and/or link to relevant
13+
tutorials or user guides.
14+
15+
Format
16+
------
17+
18+
All :ref:`examples-index` should aim to follow the following format:
19+
20+
* Title: 1-6 words, descriptive of content
21+
* Subtitle: 10-50 words, action-oriented description of the example subject
22+
* Image: a clear demonstration of the subject, showing edge cases and different
23+
applications if possible
24+
* Code + Text (optional): code, commented as appropriate + written text to add context
25+
if necessary
26+
27+
Example:
28+
29+
The ``bbox_intersect`` gallery example demonstrates the point of visual examples:
30+
31+
* this example is "messy" in that it's hard to categorize, but the gallery is the right
32+
spot for it because it makes sense to find it by visual search
33+
* :ref:`sphx_glr_gallery_misc_bbox_intersect.py`

doc/devel/content_guide/index.rst

Lines changed: 133 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,133 @@
1+
.. _documenting-content:
2+
3+
***************************
4+
Documentation content guide
5+
***************************
6+
7+
These guidelines aim to improve the consistency, cohesiveness, and organization of the
8+
:ref: documentation concerning using the library by broadly articulating the intended purpose,
9+
scope, and audience of each of the following sections:
10+
11+
:ref:`plot_types`
12+
| Summary of chart types that are implemented as high-level API
13+
14+
:ref:`User guide <users-guide-index>`
15+
| Explanations of features, components, and architecture.
16+
17+
:ref:`tutorials`
18+
| Lessons on developing visualizations
19+
20+
:ref:`examples-index`
21+
| Demonstrations of specific library features
22+
23+
:ref:`api-reference`
24+
| Descriptions of the public modules, objects, methods, and functions.
25+
26+
27+
.. note::
28+
29+
While parts of the current documentation may not yet align with these guidelines,
30+
we expect that new documentation contributions will also bring existing documentation
31+
into alignment.
32+
33+
.. note: based on note in https://matplotlib.org/3.7.3/devel/coding_guide.html
34+
35+
36+
37+
Guidelines
38+
==========
39+
40+
This content guide is heavily influenced by the `Diátaxis <https://diataxis.fr/>`_
41+
framework for technical documentation; this framework proposes that all technical
42+
documentation is roughly one of 4 types - tutorials, how-to-guides,
43+
technical reference, and explanation - and that the appropriate type is determined
44+
by whether *what* is x? (cognition) vs *how* to do x?(action) is being documented, and
45+
whether the document's purpose is *acquiring* (learning) or *applying* (using) skills.
46+
47+
Broadly, our documentation as viewed through a diátaxis lens:
48+
49+
.. list-table::
50+
:header-rows: 1
51+
:widths: 20 30 20 30
52+
53+
* - section
54+
- goal
55+
- type
56+
- example
57+
* - :ref:`plot_types`
58+
- View available chart types.
59+
- | `Reference <https://diataxis.fr/reference/>`_
60+
| what, use
61+
- :ref:`sphx_glr_plot_types_stats_pie.py`
62+
* - :ref:`User guide <users-guide-index>`
63+
- Understand features, components, and architecture
64+
- | `Explanation <https://diataxis.fr/explanation/>`_
65+
| what, learn
66+
- :ref:`annotations`
67+
* - :ref:`tutorials`
68+
- Work through the stages of building a visualization.
69+
- | `Tutorials <https://diataxis.fr/tutorials/>`_
70+
| how, learn
71+
- :ref:`sphx_glr_gallery_pie_and_polar_charts_pie_and_donut_labels.py`
72+
* - :ref:`examples-index`
73+
- Execute a visualization task.
74+
- | `How-to guides <https://diataxis.fr/how-to-guides/>`_
75+
| how, use
76+
- :ref:`sphx_glr_gallery_text_labels_and_annotations_rainbow_text.py`
77+
* - :ref:`api-reference`
78+
- Look up the input/output/behavior of public API.
79+
- | `Reference <https://diataxis.fr/reference/>`_
80+
| what, use
81+
- `.Axes.annotate`
82+
83+
Detailed guidelines for each section are documented at their respective pages:
84+
85+
.. toctree::
86+
:maxdepth: 1
87+
88+
plot_types
89+
user_guide
90+
tutorials
91+
examples
92+
api
93+
94+
95+
Audience
96+
========
97+
98+
The Matplotlib audience encompasses a wide spectrum of readers, from users who are first
99+
getting introduced to using Matplotlib through the documentation to experienced developers
100+
who want to make something extremely customized. Instead of trying to write for the
101+
entire spectrum, each document should identify its band so that reader can assess
102+
whether the document is appropriate for them. The documentation should generally use the
103+
leveling of :doc:`tags <../tag_guidelines>` and :ref:`issues <new_contributors>`, meaning
104+
that the audienced is identified based on how much contextual understanding of
105+
Matplotlib is a pre-requisite for following along with the document.
106+
107+
Documents can communicate this leveling through tags, location in the docs, and in text
108+
as appropriate. For example:
109+
110+
This guide assumes that the reader understands the general concept of Artists, as
111+
explained in :ref:`users_artists`
112+
113+
114+
Scope
115+
=====
116+
Many concepts in Matplotlib assume a grounding in visualization, statistics, Python
117+
programming, and other topics to understand how they work. These concepts should be
118+
contextualized using common terminology, but the focus for all documents should not
119+
stray from the Matplotlib topic. For example:
120+
121+
Some of the path components require multiple vertices to specify them: for example
122+
CURVE 3 is a `Bézier curve <https://en.wikipedia.org/wiki/B%C3%A9zier_curve>`_ with
123+
one control point and one end point, and CURVE4 has three vertices for the two
124+
control points and the end point. The example below shows a CURVE4 Bézier spline --
125+
the Bézier curve will be contained in the convex hull of the start point, the two
126+
control points, and the end point
127+
128+
129+
This explanation of drawing a curve using control points from :ref:`paths` never
130+
explicitly defines a *Bézier curve*, instead linking out to an external
131+
reference. This explanation is written in a manner where the definition of
132+
*Bézier curve* can be inferred from context and also understanding is not harmed if the
133+
reader does not infer the definition.
Lines changed: 14 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,14 @@
1+
.. _content-plot-types:
2+
3+
Plot types gallery
4+
==================
5+
6+
The plot type gallery displays a selection of the common visualization techniques that
7+
are implemented in Matplotlib. The gallery is heavily curated and tightly scoped to the
8+
plotting methods on `matplotlib.axes.Axes` so additions are generally discouraged.
9+
10+
Format
11+
------
12+
* very short: 5-10 lines
13+
* self explanatory data
14+
* little to no customization.

doc/devel/content_guide/tutorials.rst

Lines changed: 94 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,94 @@
1+
.. _content-tutorials:
2+
3+
Tutorials
4+
=========
5+
6+
The goal of the tutorials is to guide the reader through the stages of using Matplotlib
7+
to build specific visualization. The tutorials focus on learning how to combine the
8+
features and components that were explained in the user guide.
9+
10+
Format
11+
------
12+
13+
As with the user guide, the tutorials should aim to unpack information in chunks and
14+
build on the previous section.
15+
16+
Where the user guide explains topics like plotting and animation separately, a tutorial
17+
walks the reader through the steps involved in animating a line plot. Generally the
18+
content is limited to describing what is happening at each stage- for example there's no
19+
explanation of why an update function is written-and instead the reader is linked to an
20+
explanation.
21+
22+
#. First we start by stating the objective:
23+
24+
.. code-block:: rst
25+
26+
The goal of this tutorial is to create an animated sin wave.
27+
28+
#. Then we describe what needs to be in place to do the task. Here that is the data and
29+
object that we will animate:
30+
31+
.. code-block:: rst
32+
33+
First lets generate a sin wave::
34+
35+
x = np.linspace(0, 2*np.pi, 1000)
36+
y = np.sin(x)
37+
38+
Then we plot an empty line and capture the returned line object::
39+
40+
fig, ax = plt.subplot()
41+
l, _ = ax.plot(0,0)
42+
43+
#. With our pieces in place, we instruct the reader on how to animate the object:
44+
45+
.. code-block:: rst
46+
47+
Next we write a function that changes the plot on each frame. Here we grow the sin
48+
curve on each update by setting the new x and y data::
49+
50+
def update(frame):
51+
52+
l.set_data(x[:i], y[:i])
53+
54+
#. Next we show them how to generate the animation and describe the arguments:
55+
56+
.. code-block:: rst
57+
58+
Lastly we add an animation writer. Here we specify 30 milliseconds between each
59+
of the 40 frames::
60+
61+
ani = animation.FuncAnimation(fig=fig, func=update, frames=40, interval=30)
62+
63+
#. Then we put all the steps together to make the animated sin wave:
64+
65+
.. code-block:: rst
66+
67+
Now lets put it all together so we can plot an animated sin curve::
68+
69+
x = np.linspace(0, 2*np.pi, 1000)
70+
y = np.sin(x)
71+
72+
fig, ax = plt.subplot()
73+
l, _ = ax.plot(0,0)
74+
75+
def update(frame):
76+
l.set_data(x[:i], y[:i])
77+
78+
ani = animation.FuncAnimation(fig=fig, func=update, frames=40, interval=30)
79+
80+
#. Finally, we close with a follow up call to action to learn about the underlying
81+
concepts:
82+
83+
.. code-block:: rst
84+
85+
For more information on animations and lines, see:
86+
* :ref:`animations`
87+
* ``:ref:Line2d``
88+
89+
90+
Please note that while the aim is to show how to animate a sin curve, the focus is
91+
always on making the animation. Generally explanations of domain should be limited to
92+
providing contextually necessary information, and tutorials that are heavily domain
93+
specific may be more appropriate for the Scientific Python
94+
`blog <https://blog.scientific-python.org/>`_.

0 commit comments

Comments
 (0)