Hi all,
Please read and give feedback on a high-level proposal to change the
role of the Core WG below (starts after my sign-off). If you are a Core
WG member, contributor to the Tock repo or other repositories owned by
the Tock GitHub organization, have considered contributing to Tock, or
otherwise have a stake in Tock's direction, this affects you. If
none-of-the-above apply, you may have been mistakenly subscribed to this
mailing list :)
Note that the proposal is a draft with minimal feedback from some other
Core WG members, but is /not/ an authoritative version in any sense.
Ok... So:
We have a code review and issue triage crisis*! The scope and pace of Tock
development has outgrown the ability of a concentrated core maintainer
group to keep up with while also shepherding important foundational
aspects of Tock.
To address this, I propose that we evolve how the Tock project is
managed. The /vision/ is responsibility for Tock subsystems as well as
related ecosystem tools/projects that is completely devolved to mostly
independent working groups. The Core WG, in this vision, would primarily
serve to coordinate between working groups, establish shared design
vision, and establish/disband working groups as the needs of the project
changes. Concrete working groups, on the other hand would take on PR
review, design discussion, contribution guidelines, etc for their own
purviews. Working groups also facilitate common spaces for contributors
and users focused on specific areas to interact and
collaborate.
I think moving in this direction is important for supporting a growing
community and for avoiding some past mistakes in sherpherding and
encouraging upstream contribution, as well as making long-term
maintanence more reasonable.
Below is a draft proposal for a first step in this direction. The gist
is to formally shift the purview of the Core WG from approving all PRs
to empowering other WGs with code review and merging privileges and
serving as a backstop for issues and PRs that either fall outside of WGs
or cross WG boundaries.
But I think it's a start.
Along with this high level proposal for a role-change of the Core WG, I
envision we'd start with a working groups associated with the following
areas and purviews:
- Core
- Kernel
- The kernel crate (minus things like HILs)
- Communication (FKA networking)
- capsules/src/extra/net
- capsules/src/extra/ieee802154
- capsules/src/extra/ble*
- capsules/src/extra/usb
- capsules/src/extra/can[.rs]
- RISC-V
- chips/ibex
- chips/lowrisc
- boards/opentitan
- boards/litex
- arch/rv32i
- Userspace support for RISC-V
- Documentation
- tock-book
- doc/
- User-space libraries
- libtock-c
- libtock-rs
- libtock-[whatever-is-next]
- Testing and development infrastructure
- tockloader
- CI and test infra
- `tools/`
- Cryptography
- Capsules and HILs for AES, digests, signatures... you know... crypto stuff
- Peripherals
- Most of the rest of capsules, but specifically peripheral busses
(i2c, spi, etc..), sensors, etc
I think actually getting there is going to require more work than just
what is spelled out below: actually establishing some more working
groups and recruiting people to join them, probably some organization
restructuring of the main Tock source tree to better match the "right"
division of responsibilities, more explicit and written down shared
guidelines on what it are universal requirements for code upstream (what
does "quality code" mean, what are minimum testing and documentation
requirements, etc), and maybe others.
But this is a first step.
-Amit
*Am I exaggerating? Yes.
---
# Tock Working Groups
Working groups are focused groups to organize development around a
particular aspect of Tock.
## Motivation
Tock relies on contributions from developers with across a variety of
organizations, physical distance, timezones, and engagement. It has
also grown large in scope. This has resulted in strain on maintainers
to regularly keep up with contributions while ensuring quality and
important global policies like safety and security. It has also
resulted in contributors' work going unaddressed for long periods of
time.
Tock encompases a large and varied set of subsystems, architectures,
focus areas, libraries, ancillary tools, and documentation. Most
contributors have expertise and stake in a subset of these. Moreover,
it is impractical for any maintainer to keep up with the discussions
and direction of each part of the project. Finally, different parts of
the project should be able to move at different paces, with different
levels of scrutiny. For example, a soundness bug or performance
regression in the kernel crate can catestrophically impact all users
and should be avoided if at all possible, while a sub-optimal design
decision in an experimental user-space library is not a big deal.
To facilitate this, working groups take on responsibility for specific
sub-areas of the project. Members of a working group become experts in
that sub-area and are best able to determine appropriate scrutiny for
accepting contributions, frequency and mode of design discussions,
etc.
## Structure And Responsibilities
Tock development organizes around a core working group as well as
additional area-specific working groups. The core working group
oversees the project wholistically, defining high-level design goals
and project direction, establishing working groups, and facilitating
work that spans multiple working groups. Other working groups
facilitate contributions to specific sub-areas of the project, with
devolved decision making resposibility for accepting contributions,
design, and direction.
While working groups *oversee* development, working group members are
not expected to be the primary source of contributions. Instead,
working groups establish code review standards, define and communicate
specific design direction for their purview, and ensure relevant
contributors are both supported and effective.
### Working Group Organizational Guidelines
Each working group will have a Lead who assembles the working group
membership and is responsible for its operation.
Each working group should include at least one member from the Core
Working Group to ensure that the Core Working Group is regularly
updated on the activities and motivations of the working group. The
Core Working Group member need not be the working group Lead.
Each working group, including the Core Working Group, establishes its
own rules and procedures for accepting contributions, communicating,
meeting, and making decisions. In absense of such rules, working
groups will make decisions by consensus, have weekly voice calls, make
meeting notes available publicly, and communicate asynchronously via a
mailing list.
However, working groups are encouraged to avoid consensus-based
decision making as quickly as possible and establish appropriate
meeting frequency and communication mode for their needs and
membership.
## Core Working Group
The Core Working Group shepherds and oversees the Tock OS and related
tools and libraries. Importantly, it serves as a backstop for managing contributions that fall outside the purview of existing working groups. It also establishes new working groups to handle such contributions, and dissolves or re-organizes existing working groups.
Formally, the Core Working Group controls who can directly commit to all Tock
project repositories and devolves the ability to commit to specific
repositories or components of repositories to other working
groups. The Core Working Group, like other working groups, establishes
its own rules for deciding how to accept contributions as well as how
to establish and disband working groups.
The Core Working Group's duties are:
- Managing and overseeing code, documentation, testing, and releases
for the Tock project.
- Defining and communicating overall project goals and direction.
- Establishing and delegating responsility over components and
sub-projects to working groups.
- Ensuring that working groups have the people and resources needed
to accomplish their work.
- Ensuring working groups are accountable to their delegated
responsibilities and the project as a whole.
- Coordinating decisions including (but not limited to) code,
documentation, testing, and releases that affect purviews
delegated to more than one working group.
- Facilitating communication channels and consensus among working
groups.
- Coordinating project-wide changes to teams, structures, or
processes.
