Start to document maintainer responsibilities

In the past, a number of contributors have inquired about what bmcweb
maintainers do, and how they can become one.  As bmcweb grows in
popularity and scope, it's important that we be able to spread out the
load amongst more maintainers, and make sure that we're including
community members, while still keeping the core principles that made
bmcweb attract so many users intact.

To that end, I've attempted to document, in the OWNERS file, the basic
responsibilities that are required to be a maintainer within bmcweb.  I
very much expect that this list evolves over time, but this is expected
to be a starting point, and a place to point people that are interested
in becoming a maintainer of bmcweb.

As a pattern, I would like to see this kind of "how to be a maintainer
of this component" called out in more repositories, as I believe it
opens up the community to more people, common solutions, and better
results.

Signed-off-by: Ed Tanous <edtanous@google.com>
Change-Id: Id156edd7e340df9432bf5a8a73e8a117b5d4099a

1 files changed, 68 insertions, 0 deletions

diff --git a/OWNERS b/OWNERS
index 4c62b2853e..bbd40b0ac3 100644
--- a/OWNERS
+++ b/OWNERS
@@ -1,6 +1,74 @@
+# Below lists the current bmcweb maintainers.  bmcweb is used in a number of
+# different contexts, and is one of the few nearly-universally used core
+# components in OpenBMC.  As such, given the severe consequences of mistakes
+# made within the codebase, maintainers on this list are expected to:
+# - Have a solid understanding of the bmcweb core code, and how it's used.
+#
+# - Have access to at least one upstream platform to test relevant patchsets.
+#
+# - Help to manage the orderly merging of patchsets onto master through review.
+# It is expected that bmcweb maintainers participate on a majority of code
+# reviews, and although maintainers may work with each other to segment the
+# responsibilities into sub-parts the codebase, it is expected that maintainers
+# should be capable of reviewing all code in all modules if the need arises.
+#
+# - Provide help in testing and triage of cross-platform issues that arise as a
+# result of merging new features.
+#
+# - Have an in-depth understanding of the Redfish standard, its constraints in
+# how it interacts with OpenBMC, and how the bmcweb implementation compares to
+# other Redfish instances and how changes effect compatibility with other
+# Redfish services compatibility.
+#
+# - Be capable of, and have a track record of posing questions, clarifications,
+# and specification changes to [DMTF](https://www.dmtf.org/standards/redfish)
+# for resources implemented within the Redfish standard.  bmcweb maintainers
+# regularly attend the Redfish specification meetings to have a handle on
+# "intent" behind Redfish APIs.  In many cases, the role of the maintainer
+# requires knowing when a Redfish resource is underspecified, and direct people
+# to the standard before their changes can be accepted.
+#
+# - Have an understanding of, and track record of executing the various test
+# harnesses that bmcweb needs to pass, listed in CLIENTS.md, and at least a
+# rudimentary understanding of their requirements, and limitations.
+#
+# - Have an understanding of DBus and the specific implementations of sdbusplus
+# APIs that bmcweb uses, and their limitations in versioning, consistency, and
+# general implementation completeness.
+#
+# - Join and answer questions of the #bmcweb-and-redfish channel within
+# discord.
+#
+# - Join and answer architecture queries posed to the mailing list concerning
+# bmcweb.
+#
+# - Be capable of responding to CVE queries forwarded from the
+# [openbmc-security-response-team]
+# (https://github.com/openbmc/docs/blob/master/security/obmc-security-response-team.md).
+# Considering that in most implementations of the OpenBMC security model,
+# bmcweb is the primary attacker/client facing application on the network, it
+# is expected that a number of potential CVEs will be posted, for which bmcweb
+# forms a component of the alleged attack.  Maintainers should be prepared to
+# respond to such requests in the timeframe required by the CVE process, and
+# ideally should have a track record of doing it in the past.
+#
+# - Understand the webui variants (webui-vue and phosphor-webui) that bmcweb
+# can optionally host, its use cases, and how they differ from "normal" client
+# based use cases, as well as an understanding of hosting web services in
+# general.
+#
+# If you believe you meet the qualifications for the above, please open a
+# patchset, adding your name to the list below, documenting some evidence of
+# the above requirements being met, and the existing maintainers will happily
+# add you to the list.
+
 owners:
 - ed@tanous.net
 - gmills@linux.vnet.ibm.com
 
+
+# The below specifies a list of reviewers and interested parties that should be
+# included on code reviews to stay informed of progress.
+
 reviewers:
 - krzysztof.grobelny@intel.com