A good test case:
https://gitlab.com/snowdrift/design/issues/111
@mray and @msiep particularly pinging you here
We should use these guidelines to settle on proposals so we can move forward as effectively as we can. We have consent on a good driver for this situation already. We now have a couple starts of proposals (a “status” link vs a “not quite functioning” or similar text). We’re somewhere through Proposal Forming
So, do either of you specifically want anyone else involved? Either it’s between you two or you and whoever else you feel should be invited. (None of this is technically difficult, so there’s no need to get input from the coding side).
Key point:
Proposals become agreements when they are considered good enough for now and safe enough to try until the next review.
So, keep that in mind. I like that phrasing better than “perfect is enemy of the good”.
Note also:
An objection is an argument demonstrating (or revealing) how a (proposed) agreement or activity can lead to unintended consequences, or that there are worthwhile ways to improve it.
So, we shouldn’t agree on a proposal if there are any unresolved objections. We don’t want to move ahead just because a proposal isn’t harmful. We do want to optimize it if we have objections and/or concerns that will readily help improve the proposal.
I just suggest this is a useful framing as we work to get to agreement. I hope we can put this into practice in ways that help us. I don’t want it to be a rigid formula for its own sake, of course.