> -----Original Message----- > From: Andreas Heigl [mailto:andr...@heigl.org] > Sent: Tuesday, January 12, 2016 5:34 PM > To: Zeev Suraski <z...@zend.com>; Eli <e...@eliw.com> > Cc: internals@lists.php.net > Subject: Re: [PHP-DEV] Re: Anonymous voting on wiki > > Am 12.01.16 um 15:53 schrieb Zeev Suraski: > >> Can we please get clear on terms: > >> > >> 1. "Anonymous vote" in my eyes is a vote where no one is and will be > >> able to get information on who voted what. Never! Ever! The vote is and > >> will remain anonymous. > >> > >> 2. "Public vote" on the opposite is where everyone knows even during > the > >> voting period who voted how. In Germany there's the so called > >> "Hammelsprung" where the members of the house vote by passing > through > >> certain doors. One could influence them while queuing up for the door ;) > >> > >> 3. An "Anonymous vote during voting period" vote that is anonymous > >> during the voting period (so no one can be actively influenced to > >> changing their vote) but after the voting period is over the vote is > >> publicly available. So everyone knows who voted what. > > > > Personally, I think we should stick with #2 except for (maybe) where there > are extreme circumstances that require otherwise. Primarily along the lines > of Peter's note, if people are afraid of the repercussions. And like Peter, I > don't believe we're there at all. > > Personally I see it like that as well. But *if* we allow some kind of > otherwise voting, *which kind* of otherwise voting will we be using? And > under what circumstances will we be using this otherwise voting? what > are those "extreme circumstances"? Who defines them? Will they be on > CoC-Topics only? Or might they become available on language-topics as well?
Thinking out loud - probably votes that the current RFC process was never intended to handle. Like the current (or other) CoC RFC, and perhaps changes to the RFC process. I think that whether we need anonymous voting or not is just a part of the question. I don't think it makes sense for something 'constitional' like that to use the same rules that were designed to handle language features and administrative decisions like timelines. That is, by the way, exactly what I mean when I say that once systems are in place - they get used, including in ways that those that put them in place certainly did not predict or intend to. One of the challenges we had when we instated the Voting RFC, is that there was no process for this 'bootstrapping'. We're in the same situation now, as we do not have a process for instating a part of a 'constitution'. Before the RFC process, we used to be in a situation where for every proposal, big, medium or small, we strived for consensus and only if & when we were close enough to consensus (on internals) - we went ahead with the idea. Using that approach, we put the RFC process to a vote, and we didn't even have clear guidelines as to what would constitute a 'pass'. That RFC - clearly a big one - passed with 92% in favor - 36 to 3, and I think it's fair to describe it as 'close enough to consensus'. I strongly believe we need something similar for a CoC (whether it's the current one on the table or another one). If we did - it would inherently push authors to ensure that they're reaching near-consensus state before moving to a vote, which is the antithesis to the current situation. If & when we had such a proposal on the table, it would make the whole issue on whether or not the vote is public or anonymous irrelevant. Zeev I was hoping that the CoC would evolve into something that's a lot less divisive, but as of now, that doesn't seem to be the case. I don't
