|RFC: Revise voting protocol to enforce discussion of measures||Bernhard Schussek||12/5/12 1:47 AM|
I have created a PR  that adds a new clause to the voting protocol:
"Only measures that have been discussed with the community for at least 7 days on the FIG Mailing List may be voted upon."
7 days is an arbitrary number that we can change. I think it's long enough to allow for a discussion, but also short enough to act quickly.
The reason for the PR is basically Paul M. Jones' quote from his blog post entry on the FIG :
"We did start out with a closed list years ago, but we opened it up pretty quickly thereafter. Anyone can join in and make their voice heard.
There’s nothing “closed” about the list or the decision-making process. Anyone who wants to drive the group to open even further is free to join the list and make suggestions for doing so."
And further down the line:
"The only people who can vote on a measure are the voting members. But anyone can discuss the measures on the list."
This PR simply makes these statements a rule in order to prevent the FIG from creating proposals without letting the community at least participate in the discussion.
Let me know what you think.
|Re: RFC: Revise voting protocol to enforce discussion of measures||Jordi Boggiano||12/5/12 1:56 AM|
> This PR simply makes these statements a rule in order to prevent the FIGI think this just leads to more bureaucracy. I would like to think we
are grown up enough here that we can use common sense vs "laws" for
I might add that if the goal of the members is to screw the community
(which is quite an absurd idea IMO.. we all are the community) then your
rule doesn't really prevent that. We can potentially let the discussion
run for 7 days and then ignore all community input and do what we want
anyway. I am not saying it's what we should do or what we are doing, but
your PR does not prevent any misbehaving, it just adds cruft.
@seldaek - http://nelm.io/jordi
|Re: RFC: Revise voting protocol to enforce discussion of measures||Bernhard Schussek||12/5/12 2:04 AM|
Why do you have a voting protocol at all if we're all grown up enough to follow our common sense anyway?
This is not about bureaucracy, it's about clarity. Do you want to involve the community? Paul says yes. Make an official statement by including that in your voting protocol, then you have a solid argument for everyone calling the FIG an elitist group.
2012/12/5 Jordi Boggiano <j.bog...@seld.be>
|Re: RFC: Revise voting protocol to enforce discussion of measures||Drak||12/5/12 2:18 AM|
With all due respect, are you suggesting that voting members are not independently intelligent enough to vote down things they do not agree with? If the proposal sucks, it's going to get a lot of -1 votes or even worse, it'll get the silent treatment and not even reach quorum. We've seen that happen already, especially with membership requests. Let's not get all Monty Python about this and have to have votes about whether we should vote. The precipitating issue here was already discussed to death on and off and Jordi moved to vote in a proposal.
|Re: RFC: Revise voting protocol to enforce discussion of measures||Paul Dragoonis||12/5/12 3:19 AM|
I don't personally want to stick a 7 day discussion on everythign that goes through here.
If we're discussing whether or not we should suffix a class with 'Interface' or not, we don't need to spent 7 days wasting our time on that. it can go quickly straight to vote after 2-3 days of hearing all the points to be made.
If we're discussing something complex like HTTP interface or Caching interface then clearly things need though through for at least a few weeks.
How about we stick a minimum of 3 days onto the voting-protocols page which will keep both sides of the fence happy. Like i said above anything complex and detailed will not go to vote in 3 days, more like 3 weeks.
|Re: RFC: Revise voting protocol to enforce discussion of measures||Jake Bell||12/5/12 5:49 AM|
I tend to be on the side of less bureaucracy generally, but I would like to see some formal agreement to discuss all bylaws before they are passed. The PHP-FIG group really does stand to determine long-lasting standards for writing PHP code, so before things like "all interfaces will be suffixed with the word Interface" are passed, and all PHP developers from here on out start doing that, I think a chance to weigh in should be required.
I think something like a 7 day waiting period between posting a bylaw and voting on it is good. I understand the need to act quickly on certain issues, but 7 days is not too much. PHP has sucked for 10+ years, but that hasn't stopped any of us. :-)
|Re: RFC: Revise voting protocol to enforce discussion of measures||Paul Jones||12/5/12 6:57 AM|
I really don't like the amount of time that it takes to get something through. For example, we have two weeks for the voting period, when I really think one week would do.
However, I do think it's important that nobody feels like a vote is getting sprung on the list by surprise. I understand that there was some discussion about interface naming, but it was a side discussion arising out of related topic, not a discussion that was obviously leading to a vote.
So, in the interest of making sure we have a defined period of community input on things where we expect there to be a vote, I can totally get behind a formal process where we have a specific amount of time for discussing proposals to be voted on. Anthony Ferrara posted some notes about this earlier. I think a week would be good, but it might actually need more than that (which I hate but might be necessary to increase good-will).
In addition, we need to mark the threads in a way that we know it's not a sidebar, but something that is leading toward a vote.