[PATCH v3 0/3] Maintainer Entry Profiles

[Dan Williams <dan.j.williams@intel.com>]

Changes since v2 [1]:
- Drop any consideration for coding style concerns in the profile. It
  was a minor aspect of the proposal that generated the bulk of the
  feedback on v2. Lets make progress on the rest.

- Clarify that the "Submit Checklist Addendum" can also include details
  that submitters need to take into account before even beginning to
  craft a patch. This is in response to the RISC-V use case of
  declaring specification readiness as a patch gate, and is now also used
  by the libnvdimm subsystem to clarify details about ACPI NVDIMM Device
  Specific Method specifications. (Paul)

- Non-change from v2: Kees had asked for a common directory for all
  profiles to live, but Mauro noted that this could be handled later
  with some scripting to post-process the MAINTAINERS file, or otherwise
  converting MAINTAINERS to ReST.

- Clarify the cover letter to focus on the contributor focused
  Maintainer Entry Profiles, and defer discussion of a maintainer
  focused Handbook.

[1]: https://lore.kernel.org/ksummit-discuss/156821692280.2951081.18036584954940423225.stgit@dwillia2-desk3.amr.corp.intel.com/

---

At last years Plumbers Conference I proposed the Maintainer Entry
Profile as a document that a maintainer can provide to set contributor
expectations and provide fodder for a discussion between maintainers
about the merits of different maintainer policies.

For those that did not attend, the goal of the Maintainer Entry Profile
is to provide contributors documentation of patch submission
considerations that may vary by subsystem. The session introduction was:

    The first rule of kernel maintenance is that there are no hard and
    fast rules. That state of affairs is both a blessing and a curse. It
    has served the community well to be adaptable to the different
    people and different problem spaces that inhabit the kernel
    community. However, that variability also leads to inconsistent
    experiences for contributors, little to no guidance for new
    contributors, and unnecessary stress on current maintainers.

To be clear, the proposed document does not impose or suggest new rules.
Instead it provides an outlet to document the existing unwritten
policies in effect for a given subsystem.  Over time the hope is that
some of this variability can be up-levelled to new global process
policy, but in the meantime it provides relief for communicating the
guidelines that are being imposed on contributors.

---

Dan Williams (3):
      MAINTAINERS: Reclaim the P: tag for Maintainer Entry Profile
      Maintainer Handbook: Maintainer Entry Profile
      libnvdimm, MAINTAINERS: Maintainer Entry Profile


 Documentation/maintainer/index.rst                 |    1 
 .../maintainer/maintainer-entry-profile.rst        |   87 ++++++++++++++++++++
 Documentation/nvdimm/maintainer-entry-profile.rst  |   59 ++++++++++++++
 MAINTAINERS                                        |   20 +++--
 4 files changed, 158 insertions(+), 9 deletions(-)
 create mode 100644 Documentation/maintainer/maintainer-entry-profile.rst
 create mode 100644 Documentation/nvdimm/maintainer-entry-profile.rst
_______________________________________________
Linux-nvdimm mailing list -- linux-nvdimm@lists.01.org
To unsubscribe send an email to linux-nvdimm-leave@lists.01.org