On 1/22/20 3:21 PM, Jonathan Corbet wrote: > Documentation should lead by example, so here's a basic maintainer entry > profile for this subsystem. > > Signed-off-by: Jonathan Corbet <corbet@xxxxxxx> > --- > Documentation/doc-guide/index.rst | 1 + > .../doc-guide/maintainer-profile.rst | 44 +++++++++++++++++++ > .../maintainer/maintainer-entry-profile.rst | 1 + > 3 files changed, 46 insertions(+) > create mode 100644 Documentation/doc-guide/maintainer-profile.rst > > diff --git a/Documentation/doc-guide/index.rst b/Documentation/doc-guide/index.rst > index c58de84c0d5b..7c7d97784626 100644 > --- a/Documentation/doc-guide/index.rst > +++ b/Documentation/doc-guide/index.rst > @@ -11,6 +11,7 @@ How to write kernel documentation > kernel-doc > parse-headers > contributing > + maintainer-profile > > .. only:: subproject and html > > diff --git a/Documentation/doc-guide/maintainer-profile.rst b/Documentation/doc-guide/maintainer-profile.rst > new file mode 100644 > index 000000000000..a4e25b13250c > --- /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@xxxxxxxxxxxxxxx. 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 have been introduced. I would prefer "that no new errors or warnings" ... > +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 > +-------------- > + > +The documentation subsystem has a single maintainer who is doing the work > +on his 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. > diff --git a/Documentation/maintainer/maintainer-entry-profile.rst b/Documentation/maintainer/maintainer-entry-profile.rst > index 3eaddc8ac56d..11ebe3682771 100644 > --- a/Documentation/maintainer/maintainer-entry-profile.rst > +++ b/Documentation/maintainer/maintainer-entry-profile.rst > @@ -99,4 +99,5 @@ to do something different in the near future. > .. toctree:: > :maxdepth: 1 > > + ../doc-guide/maintainer-profile > ../nvdimm/maintainer-entry-profile > -- ~Randy
