OWNERS: fix to match org template
There is an org-wide template that OWNERS files are expected to match.
Reuse one from another repository and update the owners to match the
previous version.
Change-Id: Ia7b5a20f65b49ca5a293ef80eb3fac8e020f573c
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
diff --git a/OWNERS b/OWNERS
index 44dd43b..57213e5 100644
--- a/OWNERS
+++ b/OWNERS
@@ -1,67 +1,48 @@
-# 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.
+# OWNERS
+# ------
#
-# - Have access to at least one upstream platform to test relevant patchsets.
+# The OWNERS file maintains the list of individuals responsible for various
+# parts of this repository, including code review and approval. We use the
+# Gerrit 'owners' plugin, which consumes this file, along with some extra
+# keywords for our own purposes and tooling.
#
-# - 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.
+# For details on the configuration used by 'owners' see:
+# https://gerrit.googlesource.com/plugins/owners/+/refs/heads/master/owners/src/main/resources/Documentation/config.md
#
-# - Provide help in testing and triage of cross-platform issues that arise as a
-# result of merging new features.
+# An OWNERS file must be in the root of a repository but may also be present
+# in any subdirectory. The contents of the subdirectory OWNERS file are
+# combined with parent directories unless 'inherit: false' is set.
#
-# - 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.
+# The owners file is YAML and has [up to] 4 top-level keywords.
+# * owners: A list of individuals who have approval authority on the
+# repository.
#
-# - 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.
+# * reviewers: A list of individuals who have requested review notification
+# on the repository.
#
-# - 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.
+# * matchers: A list of specific file/path matchers for granular 'owners' and
+# 'reviewers'. See 'owners' plugin documentation.
#
-# - 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.
+# * openbmc: A list of openbmc-specific meta-data about owners and reviewers.
+# - name: preferred name of the individual.
+# - email: preferred email address of the individual.
+# - discord: Discord nickname of the individual.
#
-# - 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 webui-vue, 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.
+# It is expected that these 4 sections will be listed in the order above and
+# data within them will be kept sorted.
owners:
- ed@tanous.net
- patrick@stwcx.xyz
+reviewers:
+
+matchers:
+
+openbmc:
+- name: Ed Tanous
+ email: ed@tanous.net
+ discord: edtanous
+- name: Patrick Williams
+ email: patrick@stwcx.xyz
+ discord: stwcx