Creating an infrastructure working group
Ted Hess
thess at kitschensync.net
Fri Jun 12 12:36:12 PDT 2026
Baptiste -
You deserve better than just "crickets" as a response to your request.
As a somewhat "retired" member of OpenWrt and maintainer of the Forum
with occasional forays into keeping our other services operational, I'd
like to say that I agree to most of what you are requesting. The main
problem we have as I see it, is there is NO coordination among ourselves
mostly due to diverse interests, time and/or inclination towards action.
Our so-called infrastructure is pretty diverse as well:
- The folks interested in our build systems and downloads wrestle
continuously with resources and stability.
- Our repositories have had little attention paid to availability and
use. Just moving to a different platform doesn't solve anything - we
usually just end up trading one problem for another.
- That leaves the systems which provide service, documentation and help
to our community. The forum, wiki, freescout, mailing lists, firmware
selector and sys-upgrade operations each have their own set of
"champions" and sometimes maintainers.
- The moderation required for the forum and wiki has been for the most
part volunteers who are not voting members. I feel it is important to
continue this practice. Our wiki has suffered from the lack of
moderation and management for the last 2 years.
I appreciate your attempt to wrap your arms around this and proposing a
whole set of new rules and processes. From my view of the situation, I
think it would be best to start by getting a group together of anyone
who is willing to put in the time. We should start by inventorying our
needs and resources (just how up-to-date is:
https://openwrt.org/infrastructure) and actually get a plan of attack to
stabilize, move, upgrade or whatever is needed in the short-term. This
includes assigning responsible individuals and keeping a record of our
work as you have stated. After that, we can try formalize the process -
"architecture decision record", etc.
Right now, I'd be very happy to participate in any organizational
meeting(s) you schedule with some mandatory attendees. Getting a list of
work-items (major and minor) with names attached to them would be a
great leap forward. And of course, a place to document them.
Sorry for the rant,
/ted
On 6/4/2026 7:00:28 PM, "Baptiste Jonglez" <baptiste at bitsofnetworks.org>
wrote:
>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
>
>_______________________________________________
>openwrt-adm mailing list
>openwrt-adm at lists.openwrt.org
>https://lists.openwrt.org/mailman/listinfo/openwrt-adm
More information about the openwrt-adm
mailing list