[PATCH] Add a maintainer entry profile for Documentation/

[PATCH] Add a maintainer entry profile for Documentation/

[Jonathan Corbet]

Documentation should lead by example, so here's a basic maintainer entry
profile for this subsystem.

Signed-off-by: Jonathan Corbet <corbet@lwn.net>
---
 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@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 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
+--------------
+
+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
-- 
2.24.1

Re: [PATCH] Add a maintainer entry profile for Documentation/

[Randy Dunlap]

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@lwn.net>
> ---
>  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@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 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

Re: [PATCH] Add a maintainer entry profile for Documentation/

[Jonathan Corbet]

On Wed, 22 Jan 2020 15:50:32 -0800
Randy Dunlap <rdunlap@infradead.org> wrote:

> > +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" ...

Easily added, thanks.

jon

Re: [PATCH] Add a maintainer entry profile for Documentation/

[Matthew Wilcox]

On Wed, Jan 22, 2020 at 04:21:40PM -0700, Jonathan Corbet wrote:
> +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.

Odd change of person in this paragraph ... should it be first or second?