Document how 2i2c thinks about gatekeeping features and how it relates to team time and support

[choldgraf]

• In general, we do not gate features based on membership tier.
• However, we do protect our time based on membership tier.
• If you are a higher-tier, we will be able to give you more time in support and feedback.
• As a rough guide:
  • Essential tier: We will review straightforward PRs to our infrastructure/ repo that you make, and that's about it.
  • Advanced and Premier tier: We will provide support or guidance based on a fixed amount of time budget we have each month, beyond which we won't be able to provide support.
  • Practically, this means that if you want to do something that will require input from a 2i2c team member, advanced+ is best.

[yuvipanda]

Thanks for bringing this up, @choldgraf.

I'll copy my messages from slack

Let me try to articulate what I mean by 'this workflow':

Communities creating PRs against our infrastructure repository is not gated by tier.

I wasn't talking about:

1. Self merging (currently reserved for very few communities, with very limited scope for expansion because it can be very hard. VEDA doesn't self merge PRs today)
2. Feature gating (I agree we will gate features differently based on tier)

We currently treat opened PRs the same way we treat support tickets, and should be treated as support work, drawing from the same bucket of time that support work takes. This means that if someone from essential opens a really complex PR, we should be able to say 'hey you are out of support hours, here are the options'.

I see the following problems be surfaced by this conversation that are critical to fix:

1. What is the source of truth for our various tiers and the principles by which we put things there? I don't know where this is (particularly the principles), and that is a major problem. Or maybe this document exists and I don't know where that is, which then becomes a me problem to fix (please point me to it)
2. As far as I know, we aren't tracking 'hours spent on support per community' so we don't know when this should be bounced.
3. We don't explicitly mark 'PRs opened by communities' as a source of incoming support, although we handle it as such. I'll work on this.

I can make progress on (3) alone, but not (1) and (2).

[yuvipanda]

https://github.com/2i2c-org/meta/issues/2748 potentially feels related, but I'm also aware a lot of work was done on measuring how much time we spend on providing services to communites and gating that (which we absolutely should). I looked around to see where this was recorded, and all I could find was documented in https://github.com/2i2c-org/meta/issues/2748#issuecomment-3453508062 which doesn't seem active.

[yuvipanda]

I opened an issue about documenting the current setup in 2i2c-org/team-compass#1028

[yuvipanda]

I also caution against the contents of the issue - I think it's mostly a reflection of our lack of single source of truths. For example, I don't believe 'In general, we do not gate features based on membership tier.' is true. But what features we do and don't gate is related to 'However, we do protect our time based on membership tier.'. I don't want to dive into the details here, but that we're relitigating this again is a strong signal to me that we really have a critical gap with respect to sources of truth. I want to address that first, as otherwise I feel this will just end up happening again.