[PATCH] D106917: Security: make peoples' phab names obvious; recommend phab as the place for nominations

Tue Jul 27 14:25:32 PDT 2021

george.burgess.iv created this revision.
george.burgess.iv added reviewers: ab, apilipenko, dim, emaste, kristof.beyls, mattdr, ojhunt, probinson, peter.smith, pietroalbini, serge-sans-paille, Shayne.
george.burgess.iv requested review of this revision.
Herald added a project: LLVM.

This commit contains two mildly separate concepts; happy to split them out if folks prefer.

First, sending out reviews for things like this is a bit of a complicated endeavor, since the reviewer list is relatively long, and I generally rely on prior CLs in this area to find an authoritative list. Life's quite a bit easier if phab usernames are readily available on the doc. I was unable to locate accounts for the folks who have `[]` next to their names. If it's intended that some people on the list don't have phab accounts, I'm happy to leave those blank (though slightly concerned that these peoples' voices might not be getting heard on Phabricator code reviews).

Second, it seems to me that, at the moment, Phabricator makes the most sense for membership changes (incl. security group nominations). My reasoning for this is detailed in the diff, and to some extent in comment #1 of this bug <https://bugs.chromium.org/p/llvm/issues/detail?id=12#c1>. This change adds prose to recommend the use of Phabricator for nominations as a result. Happy to consider alternatives/etc if others have different opinions (especially given the other change in this patch).


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D106917

Files:
  llvm/docs/Security.rst


Index: llvm/docs/Security.rst
===================================================================

--- llvm/docs/Security.rst
+++ llvm/docs/Security.rst
@@ -31,24 +31,24 @@
 Security Group Members
 ----------------------
 
-The members of the group represent a wide cross-section of the community, and meet the criteria for inclusion below.
-
-* Ahmed Bougacha (Apple)
-* Artur Pilipenko (Azul Systems Inc)
-* Dimitry Andric (individual; FreeBSD)
-* Ed Maste (individual; FreeBSD)
-* George Burgess IV (Google)
-* Josh Eads (Sony)
-* Kate McInnes (Apple)
-* Kristof Beyls (ARM)
-* Matthew Riley (Google)
-* Oliver Hunt (Apple)
-* Paul Robinson (Sony)
-* Peter Smith (ARM)
-* Pietro Albini (individual; Rust)
-* Serge Guelton (RedHat)
-* Shayne Hiet-Block (Microsoft)
-* Steve Klabnik (Oxide Computer Company; Rust)
+The members of the group represent a wide cross-section of the community, and meet the criteria for inclusion below. The list is in the format `* ${full_name} (${affiliation}) [${phabricator_username}]`. If a phabricator username for an individual isn't available, the brackets will be empty.
+
+* Ahmed Bougacha (Apple) [ab]
+* Artur Pilipenko (Azul Systems Inc) [apilipenko]
+* Dimitry Andric (individual; FreeBSD) [dim]
+* Ed Maste (individual; FreeBSD) [emaste]
+* George Burgess IV (Google) [george.burgess.iv]
+* Josh Eads (Sony) []
+* Kate McInnes (Apple) []
+* Kristof Beyls (ARM) [kristof.beyls]
+* Matthew Riley (Google) [mattdr]
+* Oliver Hunt (Apple) [ojhunt]
+* Paul Robinson (Sony) [probinson]
+* Peter Smith (ARM) [peter.smith]
+* Pietro Albini (individual; Rust) [pietroalbini]
+* Serge Guelton (RedHat) [serge-sans-paille]
+* Shayne Hiet-Block (Microsoft) [Shayne]
+* Steve Klabnik (Oxide Computer Company; Rust) []
 
 Criteria
 --------
@@ -85,8 +85,9 @@
 
 Anyone who feels they meet these criteria can nominate themselves, or may be nominated by a third party such as an existing LLVM Security Group member. The nomination should state whether the nominee is nominated as an individual, researcher, or as a vendor contact. It should clearly describe the grounds for nomination.
 
-*FUTURE*: where nomination occurs (mailing list, GitHub, etc), can be decided later. See `Discussion Medium`_ below.
+For the moment, nominations are generally proposed, discussed, and voted on using Phabricator. An `example nomination is available here`_. The use of Phabricator helps keep membership discussions open, transparent, and easily accessible to LLVM developers in many ways. If, for any reason, a fully-world-readable nomination seems inappropriate, you may `open a new issue`_, and a discussion can be had about the best way to approach nomination, given the constraints that individuals are under.
 
+Our recommended method of nomination may change as our `Discussion Medium`_ story evolves over time.
 
 Choosing new members
 --------------------
@@ -226,3 +227,4 @@
 .. _GitHub security: https://help.github.com/en/articles/about-maintainer-security-advisories
 .. _llvm-dev mailing list: https://lists.llvm.org/mailman/listinfo/llvm-dev
 .. _MITRE: https://cve.mitre.org
+.. _example nomination is available here: https://reviews.llvm.org/D99232


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D106917.362178.patch
Type: text/x-patch
Size: 3180 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20210727/25376749/attachment.bin>
