Because our SRM is not granular enough, it is hard to tie its items to specific things that we might do, or that others might do. This leads to mismatches in expectations of when something is our responsibility vs. others'.
Because we don't provide a high-level description of the support model, communities may not have the right mental model in understanding what they should do vs. what we should do.
Because our SRM only discusses 2i2c and other communities, we may miss opportunities to partner with multiple communities in one service.
Proposal
Refine our Shared Responsibility and Support models to be more explicit about what needs to be done and who is in charge of what, with the goal of resolving some of the problems described above. We should define the description in docs.2i2c.org as the "source of truth", and refer to it from our Team Compass (I think this should live underneath Product in the TC).
Context
We define our Shared Responsibility Model here. In that model, we break down several different tasks along a spectrum of
2i2c <--> Community
.We ways to ask for Support here but do not provide an overview of what kinds of support we offer or the model we follow. We also discuss support in our SLOs page.
There are a few challenges with this:
Proposal
Refine our Shared Responsibility and Support models to be more explicit about what needs to be done and who is in charge of what, with the goal of resolving some of the problems described above. We should define the description in docs.2i2c.org as the "source of truth", and refer to it from our Team Compass (I think this should live underneath
Product
in the TC).Updates and actions
No response