| .. 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/devicetree), 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. | |
| All new documentation (including additions to existing documents) should | |
| ideally justify who the intended target audience is somewhere in the | |
| changelog; this way, we ensure that the documentation ends up in the correct | |
| place. Some possible categories are: kernel developers (experts or | |
| beginners), userspace programmers, end users and/or system administrators, | |
| and distributors. | |
| 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. |