Creating an infrastructure working group

[Baptiste Jonglez]

Hello,

I would like to start a discussion about our infrastructure and the people
managing it.  This has been discussed in various forms in the last few
years, so here is an attempt to explicitly create an "infrastructure group
group" with clear rules based on these earlier discussions.  After the
discussion, I will propose a vote.

Some people have had admin access since the reboot; other people --like me
and Paul-- have been gaining access progressively but did not really
"officially" became admins; some people are no longer active.  Everybody
has limited time to spend on the infrastructure, and this is
understandable because it is only a "support function" for the project
(but nonetheless an important function).

The main issues are: it's not clear who is responsible for the
infrastructure; how new members can join; how the group is organized; how
to take major technical decisions about the infrastructure; how to ensure
that systems are well-maintained.

The proposal for this new "infrastructure working group" should leave some
form of autonomy to the group in its technical decisions, but should also
keep the group accountable (e.g. at least have transparency).
It should obviously also conform to our project rules [1].

Here are some ideas for how this working group could work:

- the mission of the working group is to maintain the technical
  infrastructure necessary for the OpenWrt project to accomplish its
  main mission, in accordance to guidelines set in the project rules.

- only active project members (as defined in the rules [1]) can be part of
  the working group.

- the list of current and past working group members must be published and
  kept updated.

- the working group should meet regularly to discuss its technical
  strategy and to maintain a group dynamic.  It is recommended to hold at
  least 4 meetings every year.

Accountability:

- meeting minutes of the working group must be published openly (with
  sensitive information removed).

- the working group must publish the list of services and systems it
  manages, as well as the person who is primarily responsible for each
  one.

- the working group must keep a public log of its work.  The working group
  will decide how to do it: e.g. regular recap email, web page, git
  repository...

- project members that are not part of the group can attend working group
  meetings in a consultative manner; however, they do not take part in the
  technical decisions.

- for each major infrastructure change, an "architecture decision record"
  document [2] must be made publicly available, notified to all project
  members, and discussed within the working group.  The document must
  describe why the change is necessary (context and rationale), how it
  will be implemented at a high level (decision), and its expected impact
  (consequences).  There must be at least two weeks between the first
  publication of the document and applying the change, during which the
  document can be discussed and modified.  The final version of the
  architecture decision record must be notified again to all project
  members.  Each proposed change should get its own architecture decision
  record, in order to keep the documents short and readable.


Join/leave rules for the working group:

- there are two roles in the working group: "provisional member" and
  "confirmed member".  Confirmed members have full access to all
  infrastructure systems relevant for OpenWrt.

- any active project member can ask to join the working group as a
  "provisional" member.  To do so, they must determine and announce a
  specific infrastructure project they would like to tackle, in
  cooperation with existing working group members.  While in this
  "provisional" status, they only get access to the systems needed for
  their project, and they must perform any infrastructure action in tandem
  with an existing confirmed member (e.g. have their Ansible code
  reviewed, or pair sysadmin sessions).  If a project is finished, they
  can identify a new project to gain further accesses.

- after completing the project, and at least 6 months after joining the
  group, a provisional member can ask the rest of the working group to
  become a confirmed member.  This is discussed during the next working
  group meeting, then announced publicly to all project members, after
  which the "confirmed" status is automatically gained.

- if a project member becomes "inactive" (according to our rules [1])
  or loses its project membership status for any reason, they are
  automatically removed from the working group.

- working group members are expected to attend group meetings on a regular
  basis.  After missing 4 meetings in a row, and at least one year after
  their last meeting participation, they are automatically removed from
  the working group.

- a working group member can voluntarily leave the group by announcing it
  to all other group members.

- when a working group member leaves the group for any reason, all their
  technical infrastructure accesses are immediately revoked by another
  group member.


Baptiste

[1] https://openwrt.org/rules
[2] https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions.html