summaryrefslogtreecommitdiff
path: root/Documentation/doc-guide/maintainer-profile.rst
diff options
context:
space:
mode:
authorJonathan Corbet <corbet@lwn.net>2020-01-22 16:05:43 -0700
committerJonathan Corbet <corbet@lwn.net>2020-01-24 09:48:39 -0700
commit53b7f3aa411bb812c7a4f8af1ab9e0d2288b56cf (patch)
tree7045b082a5cfe0c0bf449f4cc4bb7772b59745f8 /Documentation/doc-guide/maintainer-profile.rst
parentd96574b0b49d6c93f148333bd36d541281fc4636 (diff)
Add a maintainer entry profile for documentation
Documentation should lead by example, so here's a basic maintainer entry profile for this subsystem. Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Diffstat (limited to 'Documentation/doc-guide/maintainer-profile.rst')
-rw-r--r--Documentation/doc-guide/maintainer-profile.rst44
1 files changed, 44 insertions, 0 deletions
diff --git a/Documentation/doc-guide/maintainer-profile.rst b/Documentation/doc-guide/maintainer-profile.rst
new file mode 100644
index 000000000000..aee2f508cc89
--- /dev/null
+++ b/Documentation/doc-guide/maintainer-profile.rst
@@ -0,0 +1,44 @@
+.. SPDX-License-Identifier: GPL-2.0
+Documentation subsystem maintainer entry profile
+================================================
+
+The documentation "subsystem" is the central coordinating point for the
+kernel's documentation and associated infrastructure. It covers the
+hierarchy under Documentation/ (with the exception of
+Documentation/device-tree), various utilities under scripts/ and, at least
+some of the time, LICENSES/.
+
+It's worth noting, though, that the boundaries of this subsystem are rather
+fuzzier than normal. Many other subsystem maintainers like to keep control
+of portions of Documentation/, and many more freely apply changes there
+when it is convenient. Beyond that, much of the kernel's documentation is
+found in the source as kerneldoc comments; those are usually (but not
+always) maintained by the relevant subsystem maintainer.
+
+The mailing list for documentation is linux-doc@vger.kernel.org. Patches
+should be made against the docs-next tree whenever possible.
+
+Submit checklist addendum
+-------------------------
+
+When making documentation changes, you should actually build the
+documentation and ensure that no new errors or warnings have been
+introduced. Generating HTML documents and looking at the result will help
+to avoid unsightly misunderstandings about how things will be rendered.
+
+Key cycle dates
+---------------
+
+Patches can be sent anytime, but response will be slower than usual during
+the merge window. The docs tree tends to close late before the merge
+window opens, since the risk of regressions from documentation patches is
+low.
+
+Review cadence
+--------------
+
+I am the sole maintainer for the documentation subsystem, and I am doing
+the work on my own time, so the response to patches will occasionally be
+slow. I try to always send out a notification when a patch is merged (or
+when I decide that one cannot be). Do not hesitate to send a ping if you
+have not heard back within a week of sending a patch.