> Currently the "Feature selection and development" basically says "we'd have > a public vote on features". It doesn't specify how exactly is the process for > a > vote, and while again I think your proposal is good, I don't see why it has > to be > part of this RFC - e.g., if we agree that we have to have RFCs and formal non- > ML public vote, let's fix that and then talk about how exactly we do the vote. > The RFC itself says nothing of "how", so I don't see why we should mix the > question of "should we do it" with "let's decide how exactly we going to do > it".
I can't really agree here. Just watch what happened last week, when we moved ahead to a vote - the whole thing was IMHO rushed and messy. That's exactly why I don't think we can leave the details out. The way I see it, we can't employ the voting part of this RFC unless we can agree on rules on how this voting works; It's fine that we don't decide exactly how we're going to do it. But then, it means that we don't get to do it until we do decide. What makes the most sense to me is to separate the decision making process into another RFC altogether. If people feel it's premature to discuss that process - that's fine, but I don't think we can hold the stick at both ends, and start using a voting mechanism before we even agreed on the basics of voting in the first place. Zeev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
