Hi folks!
Recently a change was committed 1 that no longer displays votes on active
RFCs. I think this would have merited discussion beforehand, so I'm
starting that discussion now.
I can see where this comes from (avoid herd effect?), but I don't think
it's a good idea. I can't even see votes on my own RFCs, so I don't know
how things are going and if there are still issues. Also this prevents the
"vote reason" column that was suggested in several recent discussions. That
would seem like a much more valuable change than just removing the votes.
Thanks,
Nikita
I can agree that removing the votes completely is not the right option. Perhaps show the names of those who have voted on all RFCs, but not specifically which way they voted. This would allow users to see how many votes have been casted, as well as allow the vote reason to appear (if added).
Also on own RFCs I think it’d be good to see if you can see the current tally’s.
Jeremy
Hi folks!
Recently a change was committed 1 that no longer displays votes on active
RFCs. I think this would have merited discussion beforehand, so I'm
starting that discussion now.I can see where this comes from (avoid herd effect?), but I don't think
it's a good idea. I can't even see votes on my own RFCs, so I don't know
how things are going and if there are still issues. Also this prevents the
"vote reason" column that was suggested in several recent discussions. That
would seem like a much more valuable change than just removing the votes.Thanks,
Nikita
I can agree that removing the votes completely is not the right option.
Perhaps show the names of those who have voted on all RFCs, but not
specifically which way they voted.
Sorry if it was unclear, what you describe is what has been implemented.
See for example https://wiki.php.net/rfc/argument_unpacking#vote.
This would allow users to see how many votes have been casted, as well as
allow the vote reason to appear (if added).
Hiding the vote, but displaying the reason doesn't really make sense, as
the latter would reveal the former ^^
Nikita
I agree with Nikita. I don't think we should be hiding anything here, not
who voted and not how they voted. I admit that in some cases I do care
about how certain others vote, but it doesn't make me cattle :)
Zeev
-----Original Message-----
From: Nikita Popov [mailto:nikita.ppv@gmail.com]
Sent: Monday, January 06, 2014 6:24 PM
To: PHP internals
Subject: [PHP-DEV] RFC votes no longer visibleHi folks!
Recently a change was committed 1 that no longer displays votes on
active
RFCs. I think this would have merited discussion beforehand, so I'm
starting
that discussion now.I can see where this comes from (avoid herd effect?), but I don't think
it's a
good idea. I can't even see votes on my own RFCs, so I don't know how
things are going and if there are still issues. Also this prevents the
"vote
reason" column that was suggested in several recent discussions. That
would
seem like a much more valuable change than just removing the votes.Thanks,
Nikita3f50da535616a0e
I agree with Nikita. I don't think we should be hiding anything here, not
who voted and not how they voted. I admit that in some cases I do care
about how certain others vote, but it doesn't make me cattle :)
Same here, please don't hide votes.
cheers,
Derick
--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug
Posted with an email client that doesn't mangle email: alpine
hi,
Hi folks!
Recently a change was committed [1] that no longer displays votes on active
RFCs. I think this would have merited discussion beforehand, so I'm
starting that discussion now.I can see where this comes from (avoid herd effect?), but I don't think
it's a good idea. I can't even see votes on my own RFCs, so I don't know
how things are going and if there are still issues. Also this prevents the
"vote reason" column that was suggested in several recent discussions. That
would seem like a much more valuable change than just removing the votes.
it does not make any sense. And it should not have been done without a
discussion.
@peter Please revert.
--
Pierre
@pierrejoye | http://www.libgd.org
hi,
Hi folks!
Recently a change was committed [1] that no longer displays votes on
active
RFCs. I think this would have merited discussion beforehand, so I'm
starting that discussion now.I can see where this comes from (avoid herd effect?), but I don't think
it's a good idea. I can't even see votes on my own RFCs, so I don't know
how things are going and if there are still issues. Also this prevents
the
"vote reason" column that was suggested in several recent discussions.
That
would seem like a much more valuable change than just removing the votes.it does not make any sense. And it should not have been done without a
discussion.@peter Please revert.
I’d rather see discussion on the subject than an immediate revert; not that
I’m against reverting in any way. Let’s make the changes, if we do decide
to make any, be beneficial.
The offending change was a suuuppppeeerrrr old pull request that had been
laying around forever and Hannes decided to merge it.
It had been around for such a long time that I figure any complaints would
have been raised and addressed between the initial PR [1] and now. Funny
how people like to voice their dissent after-the-fact (just an observation,
not a prompt for discussion).
CC-ing webmaster list as a more appropriate forum.
[1] https://github.com/php/web-wiki/pull/1
--
Pierre@pierrejoye | http://www.libgd.org
Hi!
I’d rather see discussion on the subject than an immediate revert; not that
I’m against reverting in any way. Let’s make the changes, if we do decide
to make any, be beneficial.
I don't think this is how it should work. This is a pretty big change in
voting process, it should be discussed first, and only then merged, if
it's agreeable. Going back to the old "first merge, then maybe discuss
if enough people protest" is not a good development. It's not the PHP
source code but the community environment now but it doesn't differ - we
should still do it the right way. I don't see this change as anything
urgent or necessary to be put in immediately, and there are obvious
objections from many people - myself included, btw. So let's please
first back off the controversial change and then discuss it.
It had been around for such a long time that I figure any complaints would
have been raised and addressed between the initial PR [1] and now. Funny
Nobody looked at this PR or knew it is going to be merged. That's why we
have a process of announcing things and initiating discussion - because
most people don't regularly review all pulls that are pending in all repos.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
I’d rather see discussion on the subject than an immediate revert; not
that
I’m against reverting in any way. Let’s make the changes, if we do decide
to make any, be beneficial.I don't think this is how it should work. This is a pretty big change in
voting process, it should be discussed first, and only then merged, if
it's agreeable. Going back to the old "first merge, then maybe discuss
if enough people protest" is not a good development. It's not the PHP
source code but the community environment now but it doesn't differ - we
should still do it the right way. I don't see this change as anything
urgent or necessary to be put in immediately, and there are obvious
objections from many people - myself included, btw. So let's please
first back off the controversial change and then discuss it.
If you insist, I would feel rude stepping on Hannes’ toes though.
It had been around for such a long time that I figure any complaints
would
have been raised and addressed between the initial PR [1] and now. FunnyNobody looked at this PR or knew it is going to be merged. That's why we
have a process of announcing things and initiating discussion - because
most people don't regularly review all pulls that are pending in all repos.--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
I’d rather see discussion on the subject than an immediate revert; not that
I’m against reverting in any way. Let’s make the changes, if we do decide
to make any, be beneficial.I don't think this is how it should work. This is a pretty big change in
voting process, it should be discussed first, and only then merged, if
it's agreeable. Going back to the old "first merge, then maybe discuss
if enough people protest" is not a good development. It's not the PHP
source code but the community environment now but it doesn't differ - we
should still do it the right way. I don't see this change as anything
urgent or necessary to be put in immediately, and there are obvious
objections from many people - myself included, btw. So let's please
first back off the controversial change and then discuss it.It had been around for such a long time that I figure any complaints would
have been raised and addressed between the initial PR [1] and now. FunnyNobody looked at this PR or knew it is going to be merged. That's why we
have a process of announcing things and initiating discussion - because
most people don't regularly review all pulls that are pending in all repos.
There also seems to be confusion here as to what exactly the change
was, and people arguing one way or the other without actually
understanding it.
This also seems very true for people that vote in general, which made
the patch look like a really good idea:
- The author of the RFC can no longer bribe and "convince" individual
person to change his/hers vote - Your vote is more meaningful now, as it could actually be the winning vote
- First 5 votes one way? No point in voting the other way (or at all)
- Last minute twitter "lets all vote yes/no to change the vote around"
doesn't work - The "I just wanna be in the winning/loosing team" is difficult
Note that all votes become public after the voting has been closed.
There is no secret here - except when the votes are being counted, the
results are "pending".
I personally think this could fix some of the flaws we have in the
voting RFC, and maybe even get more people to participate in the
voting.
The voting RFC says nothing about the individual vote needing to
actually be public even after the results are in.
It is also very unclear on who actually can vote, but thats a separate ting.
-Hannes
Hi!
There also seems to be confusion here as to what exactly the change
was, and people arguing one way or the other without actually
understanding it.
I think we understand pretty well what the change was - the change was
that individual votes can no longer be seen while the vote is in
progress. Is this understanding incorrect?
This also seems very true for people that vote in general, which made
the patch look like a really good idea:
These are all very logical arguments, and even though I disagree with
them I see where they are coming from. My main objection, though, is
that these arguments should have been brought forward before the patch
was merged, not post factum. We all agreed that that's the right way to
do things, let's abide by it.
- The author of the RFC can no longer bribe and "convince" individual
person to change his/hers vote- Your vote is more meaningful now, as it could actually be the winning vote
- First 5 votes one way? No point in voting the other way (or at all)
- Last minute twitter "lets all vote yes/no to change the vote around"
doesn't work- The "I just wanna be in the winning/loosing team" is difficult
While I see the point here, I think you are not giving enough credit to
people in the community. I've seen a number of votes, and people have
absolutely no problem dissenting or casting their vote against the
prevailing opinion, as far as I could see. But if somebody does feel
intimidated let's hear it and see how many people actually have this
issue, maybe my impression is wrong.
The voting RFC says nothing about the individual vote needing to
actually be public even after the results are in.
This is true, however we have always had open votes, so this is the
status quo. Which means changing it needs agreement, and not the silent
"facts on the ground" kind of one since it is obviously not unanimously
accepted right now.
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hannes Magnusson wrote:
Note that all votes become public after the voting has been closed.
There is no secret here - except when the votes are being counted, the
results are "pending".I personally think this could fix some of the flaws we have in the
voting RFC, and maybe even get more people to participate in the
voting.The voting RFC says nothing about the individual vote needing to
actually be public even after the results are in.
It is also very unclear on who actually can vote, but thats a separate ting.
Not having a vote I can't influence anything anyway, but I DO take note of what
people feel about various changes being proposed. From my point of view, seeing
who is supporting or opposing something influences whether I take a closer look
at something. While comments on the lists may be adequate, seeing that there are
objections via the voting is important to me! If people I respect enter what
seems to be an alternate view, then it can be picked up before voting closes
rather than when it's already a done deal?
This thread was copied to the web-master list as 'more appropriate', but is a
perfect example of where a central discussion is necessary. The new website is
now even more disjointed than it was and searching the site to review rfc's is
another casualty if decisions made elsewhere? I'm having to run searches on
saparate areas of the new site and getting excessive multilingual results for
something that a simple single search used to provide?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
- The author of the RFC can no longer bribe and "convince" individual
person to change his/hers vote
I'm unconvinced "bribery" exists. What I do know exists is that people
who make RFCs will contact people who voted No to try and see how they
can improve the RFC to be more to their liking. I can't see how this
could be a bad thing.
--
Andrea Faulds
http://ajf.me/
- The author of the RFC can no longer bribe and "convince" individual
person to change his/hers voteI'm unconvinced "bribery" exists. What I do know exists is that people who
make RFCs will contact people who voted No to try and see how they can
improve the RFC to be more to their liking. I can't see how this could be a
bad thing.
Agreed. I believe it was completely inappropriate for this change to have
been made unilaterally without a vote or even discussion. To suggest that
we should now discuss whether to revert it would be like implementing a new
feature without any discussion then proposing an RFC to remove it.
Please revert the change immediately. We can then discuss the merits of it
and vote on it as an RFC. If you have the better argument, then it will
pass. But making such a drastic change that affects the entire voting
process unilaterally would set a precedent that completely undermines the
whole point of having a voting process in the first place.
--Kris
I can see where this comes from (avoid herd effect?), but I don't think
it's a good idea. I can't even see votes on my own RFCs, so I don't know
how things are going and if there are still issues. Also this prevents the
"vote reason" column that was suggested in several recent discussions. That
would seem like a much more valuable change than just removing the votes.
I really don't like this. This isn't politics or elections, this is PHP.
We have completely open mailing list discussions, where you can see
people's opinions. I see no reason to hide people's votes. Secret
ballots are useful where privacy is particularly important. I don't see
why this is really desirable here, considering we do everything else
in the open!
--
Andrea Faulds
http://ajf.me/