Creating an infrastructure working group

[Baptiste Jonglez]

On 28-05-26, Baptiste Jonglez wrote:
> 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.

Bumping up since it didn't generate the amount of reactions I expected.

> 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.

Do other people feel the same way, about the lack of clarity of the
current situation?

Is the "working group" proposal below a good way to improve things?

> 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
> 
> _______________________________________________
> openwrt-adm mailing list
> openwrt-adm at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-adm