Formalize plugin approval process

[karashiiro]

Currently, our plugin approval process is informal and not written down anywhere. We should change that, and determine who has the final say on merges and when those people should be poked to merge things.

In the meantime, we should make an immediate preliminary decision on final merges so that we can avoid situations like this in the future. We can revise and document a final decision in a proper DIP.

Requesting feedback from @goatcorp/plugin-approval.

[NotNite]

This should probably go in the subteams DIP, but I've noticed that team URL 404s because it's set to private. Should we make the teams (and members of goatcorp, maybe) public, so people know who to ask if something takes a while?

[karashiiro]

The subteams DIP has been merged, we should create a new DIP for this.

In general, once accepted, DIPs should not be substantially changed. Only very minor changes should be submitted as amendments. More substantial changes should be new DIPs, with a note added to the original DIP.

[NotNite]

I'd argue this is a minor change - it's literally clicking the "Secret" button to public on teams, and having people who want to be publically affiliated with goatcorp turning their membership to public (if we want anyone to show up there, that is).

[karashiiro]

Oh mb, I thought you meant the whole issue. The visibility on its own is minor, yeah.

[philpax]

I've fixed the visibility on the teams with goat's permission, should be ok now 👍

[philpax]

so we on the plugin approval team have a nice spreadsheet to help out with this, but it's stalled because nobody's responsible for keeping it in sync with new plugins entering review.

think this needs a proper DIP where the basic review process is outlined, and a simple review platform is designed and built for looking at new plugins in a systematic fashion. really simple MVP stuff, and in future we can look at #34 as an endgame solution