Hi, > Personally, I'm leaning towards not having bylaws/guidelines, or at least > waiting until we see if we can get folks on general@ to clean up the voting > document.
It's not going to cover everything or if/when they can clear it up. And if they do does it apply retroactively?It seems to be the option that the default where no guidelines exist is consensus and -1 is a veto (when voting in committers). [1] [2] > I share the concern that trying to come up with these decisions will burn a > lot of time So do discussions on what is a valid vote or not and people need to be clear up front on how to vote. Most of the hard work has been done by other projects. > , like now trying to figure out how to apply consensus if there are multiple > chair candidates. Seems the answer here is to use STV voting, this is mentioned in a few project bylaws. > And really, the chair is up for review every day. No need to wait for the > end of a year if a chair is not performing to the satisfaction of the rest of > the PMC. I don't think it's a question of satisfaction, the current chair IMO is doing a fine job. It's more a question do we want to share the role around and let other people get the experience. Just like making releases and being the build manager :-) And lets just pretend the Chair isn't doing their job, what would the process be for replacing them? What would the voting system be? Would they agree with that process or the vote? Again I don't think this will ever happen but having it in written down somewhere means if it does there's going to be less issues. Not being clear on how to vote a committer in, seems to me a fundamental thing that needs to be resolved. Thanks, Justin 1. http://apache.markmail.org/thread/chfagblj72cv7zrt 2. http://markmail.org/message/tknqw3n47m3wqr63
