Allow peers to review all parts of a feature

[foolip]

Looking at https://github.com/web-platform-dx/web-features/blob/main/GOVERNANCE.md#peers it seems like peers should only review and merge feature descriptions, leaving everything else about a feature to owners.

This does not seem like a useful split of responsibilities to me. I think peers should be trusted with all parts of the data, while owners also handle infra issues, schema changes, and the like.

[atopal]

How about limiting exclusive review by an owner for PRs that are disruptive or controversial when it changes the Baseline status of a feature?

[foolip]

I'd trust peers to change the Baseline as well. The most important time to look at the Baseline status is when the feature is being added, and if peers can't review PRs that add new features, then we'll have a review bottleneck.

[atopal]

Yes, I meant specifically for PRs where the Baseline change would be disruptive or controversial.

[foolip]

I think that'd make sense for the documented expectations. I was thinking in terms of what could be made an objective rule and potentially checked in CI, but leaving things to judgment is OK sometimes too.

[foolip]

I guess the crux of this issue is what the difference between owners and peers should be. To me, the key thing is breaking changes or new features, which would cause major or minor version bumps.

[atopal]

The owners are made up of browser vendors, dev community and large consumers of the data to ensure that with any major change their interests are taken into account. Peers on the other hand don't have to have "skin in the game". So, from that perspective your list seems right to me and would be objective, and I'm guessing we'll need to leave room for decisions where the Baseline status of something in particular is controversial, which ultimately the owners group needs to decide.

[ddbeck]

I had a chat with Kadir and Philip about this on Monday. To sum up a bit:

• We haven't been following the governance doc terribly closely (though I think nearly every PR to date has had some kind of involvement from an owner), but we also haven't breaking it really. The Owner-delegate rule is also a bit of a backstop: owners can and should let reasonable things happen, even if they're not strictly in-line with the other rules (though we should strive to be more explicit about those deviations).

• When we originally created the governance document, we didn't know how well computed computed statuses would work, how controversial individual statuses might be, and how much scrutiny any one feature might get. But by now we've worked out a great many issues and have gotten to a point where:

  • computed statuses generally work (or get upstream data fixes)
  • most features are pretty boring in overview (e.g., being well-established platform features or plainly non-interoperable)
  • overrides tend to align us to external references (e.g., we're pinning to caniuse rather than bringing a fresh judgment of our own)

All this suggests to me that the risks we were most concerned about at the outset (controversy, differing opinions, bad data, etc.) have been well-managed so far, so we don't need to have so many veto points as we originally laid out.

I think we should amend the governance document such that peers are officially OK'd to add and update features, including their statuses, and reserve only feature removal* as an owner-only power. I've opened #1553 to do just that.

* At least until we sort out feature merging/composition