xref: /linux/Documentation/doc-guide/maintainer-profile.rst (revision 36a1818f5a1e50b805317ba13f827067d50f6970)
1.. SPDX-License-Identifier: GPL-2.0
2
3Documentation subsystem maintainer entry profile
4================================================
5
6The documentation "subsystem" is the central coordinating point for the
7kernel's documentation and associated infrastructure.  It covers the
8hierarchy under Documentation/ (with the exception of
9Documentation/devicetree), various utilities under scripts/ and, at least
10some of the time, LICENSES/.
11
12It's worth noting, though, that the boundaries of this subsystem are rather
13fuzzier than normal.  Many other subsystem maintainers like to keep control
14of portions of Documentation/, and many more freely apply changes there
15when it is convenient.  Beyond that, much of the kernel's documentation is
16found in the source as kerneldoc comments; those are usually (but not
17always) maintained by the relevant subsystem maintainer.
18
19The mailing list for documentation is linux-doc@vger.kernel.org.  Patches
20should be made against the docs-next tree whenever possible.
21
22Submit checklist addendum
23-------------------------
24
25When making documentation changes, you should actually build the
26documentation and ensure that no new errors or warnings have been
27introduced.  Generating HTML documents and looking at the result will help
28to avoid unsightly misunderstandings about how things will be rendered.
29
30All new documentation (including additions to existing documents) should
31ideally justify who the intended target audience is somewhere in the
32changelog; this way, we ensure that the documentation ends up in the correct
33place.  Some possible categories are: kernel developers (experts or
34beginners), userspace programmers, end users and/or system administrators,
35and distributors.
36
37Key cycle dates
38---------------
39
40Patches can be sent anytime, but response will be slower than usual during
41the merge window.  The docs tree tends to close late before the merge
42window opens, since the risk of regressions from documentation patches is
43low.
44
45Review cadence
46--------------
47
48I am the sole maintainer for the documentation subsystem, and I am doing
49the work on my own time, so the response to patches will occasionally be
50slow.  I try to always send out a notification when a patch is merged (or
51when I decide that one cannot be).  Do not hesitate to send a ping if you
52have not heard back within a week of sending a patch.
53