This is a carry-over from last week.
- The tech leads group not being a decision making body
- Whether it's realistic and/or desirable for the TC to make every technical decision
- There was some overlap here with the external code submission topic
Additional Context:
For Today:
- Review Jakub Skoczen's document and any feedback/questions/comments.
- Marc Johnson: the goal here is "to make a process"? Yes: the task is to specify the process.
- Owen Stephens: how is evaluating a proposal a decision-making process? Proposals are approved or rejected; this is the decision. This can be made more explicit in the "Goal" statement.
- Motivation: consistency! consistency! consistency! Also, to promote participation in the decision-making process.
- Marc Johnson: I thought we were trying to define a framework for the process, but achieving consistency is an outcome of having such a process, so it feels like we're confusing motivation with outcome.
- High barriers will limit participants; low barriers will reduce consistency; the goal is the middle ground.
- Owen Stephens: Should the process favor consistency over other things, or are we expecting that the process will increase consistency? We've had presentations from e.g. sysops that demonstrated conflicting priorities among ease of maintenance, feature work, etc; are we saying that consistency is our highest priority?
- Jeremy Huff: Agreed, we would have to intentionally favor consistency if we want that. Deviating from that would have to be deliberate. Should this priority be captured?
- Jakub Skoczen: we've added many criteria to our acceptance criteria, but it isn't clear that the project truly will be better off if we add additional criteria, perhaps at the expense of losing a feature that was inconsistently implemented.
- TODO for all: please review and comment on this document! Consider whether the RFC proposal can meet the purpose outlined here.