Thanks for laying this plan out, Mihir! This is a great step toward bringing the design workflow into the open source ethos. Dropping my two cents on Junlin’s questions below. On Jan 26, 2021, 9:04 PM -0800, [email protected], wrote: > > How do we define whether an issue is "settled" or not? Should we utilize the > voting mechanism same as SIP?
The process laid out in this plan follows Apache's “lazy consensus” pretty closely. I think we should be fine following that model. https://community.apache.org/committers/lazyConsensus.html > If we have a different mechanism, how do we weigh opinions from committers > vs. general users? I’m not an Apache process expert, but I don’t think there'd be any real difference, in terms of consensus-seeking. If it were escalated to a vote due to some contention, binding/non-binding status of votes would have different weighting. > How should we address future comments and concerns from people who weren’t a > part of the previous discussion after a guideline is settled in wiki? Do we > reopen the discussion? I’m curious how Mihir and others would see this, but my thinking is that the design guidelines on the Wiki would be considered a “living document” and there could always be a new proposal which would update/override the results of an older proposal (rather than re-opening an old one). The Wiki should represent the latest thinking, rather than a final/permanent state. Thanks, Evan
