Re: [PHP-DEV] RFC Process: more productive conversations
On Tue, Mar 26, 2019 at 4:02 AM Peter Bowyer wrote: > On Mon, 25 Mar 2019 at 19:28, Ben Ramsey wrote: > > > If someone enters nonsense or “n/a” or any value that doesn’t justify > > their vote or doesn’t appear to satisfactorily justify it according to > some > > metric of justification satisfaction, then does that person’s vote get > > thrown out or discounted? > > > > During the experiment, not at all. > > I'm not presupposing any outcome, and if commenting was kept after the > experiment and if it was to have an effect like you describe, it would need > to go through the RFC process and be approved. > > > > What is the goal of the experiment? > > > > To see if there's a basis in practice for the concern expressed around who > can vote and the problems it may/does cause; > To see how people respond to being asked to comment, explaining their > choice of vote; > To see what impact commenting has on the voting process. > > It would need to be run for a set period of time; perhaps best measured in > "Number of votes carried out". Completely guessed without looking at past > vote frequency, but say 4 months or 10 votes, whichever is longer. > > Peter > For this to have meaningful results, I think you would also need the ability for people to abstain, along with a comment as to why they aren't voting. -- Chase Peeler chasepee...@gmail.com
Re: [PHP-DEV] RFC Process: more productive conversations
On Mon, 25 Mar 2019 at 19:28, Ben Ramsey wrote: > If someone enters nonsense or “n/a” or any value that doesn’t justify > their vote or doesn’t appear to satisfactorily justify it according to some > metric of justification satisfaction, then does that person’s vote get > thrown out or discounted? > During the experiment, not at all. I'm not presupposing any outcome, and if commenting was kept after the experiment and if it was to have an effect like you describe, it would need to go through the RFC process and be approved. > What is the goal of the experiment? > To see if there's a basis in practice for the concern expressed around who can vote and the problems it may/does cause; To see how people respond to being asked to comment, explaining their choice of vote; To see what impact commenting has on the voting process. It would need to be run for a set period of time; perhaps best measured in "Number of votes carried out". Completely guessed without looking at past vote frequency, but say 4 months or 10 votes, whichever is longer. Peter
Re: [PHP-DEV] RFC Process: more productive conversations
> On Mar 25, 2019, at 11:56, Peter Bowyer wrote: > > On Mon, 25 Mar 2019 at 15:24, Andreas Heigl wrote: > >> Shall we then also expect people that vote "yes" to explain why they voted >> for the feature? To see whether they understood what they where voting on? >> > > Yes. > > >> Then we should couple the vote to a comment in the wikinpage and without a >> comment there's no way to vote. >> >> That way all the information would be readily available in the RFC and no >> one would need to add comments after an RFC was voted upon. Because IMO >> that information as well as the process that lead to acceptance of the RFC >> are also important to afterwards make clear why that feature was >> implememted the way it was. So all RFCs and also all voters would be >> treated the same. >> > > Yes, that is the system I would like. Whether the comments are hidden > during voting or visible I have no strong feelings - but I would like a > comment to be required to vote. As you say it is useful history. > > People may enter nonsense into the comment field. They may paste in their > message(s) from internals. I'm OK with any of that as it's an experiment. > If it's not useful, we can stop asking for a comment. > > Given the concerns raised around voting, it would be interesting to see the > effect this has. If someone enters nonsense or “n/a” or any value that doesn’t justify their vote or doesn’t appear to satisfactorily justify it according to some metric of justification satisfaction, then does that person’s vote get thrown out or discounted? What is the goal of the experiment? Cheers, Ben signature.asc Description: Message signed with OpenPGP
Re: [PHP-DEV] RFC Process: more productive conversations
On Mon, 25 Mar 2019 at 15:24, Andreas Heigl wrote: > Shall we then also expect people that vote "yes" to explain why they voted > for the feature? To see whether they understood what they where voting on? > Yes. > Then we should couple the vote to a comment in the wikinpage and without a > comment there's no way to vote. > > That way all the information would be readily available in the RFC and no > one would need to add comments after an RFC was voted upon. Because IMO > that information as well as the process that lead to acceptance of the RFC > are also important to afterwards make clear why that feature was > implememted the way it was. So all RFCs and also all voters would be > treated the same. > Yes, that is the system I would like. Whether the comments are hidden during voting or visible I have no strong feelings - but I would like a comment to be required to vote. As you say it is useful history. People may enter nonsense into the comment field. They may paste in their message(s) from internals. I'm OK with any of that as it's an experiment. If it's not useful, we can stop asking for a comment. Given the concerns raised around voting, it would be interesting to see the effect this has. Peter
Re: [PHP-DEV] RFC Process: more productive conversations
> Am 25.03.2019 um 15:39 schrieb Peter Bowyer : > >> On Mon, 25 Mar 2019 at 14:02, Dan Ackroyd wrote: >> >> I don't believe forcing people to explain their votes actually does that. >> >> It does something quite similar, of forcing people to try to >> articulate how the RFC needs to change for them to change their vote >> from a no to a yes. At least that is how I have perceived the >> intentions of people who have asked for 'no' voters to explain their >> vote. >> > > It also ties in with the view previously expressed that we should restrict > voting rights because (my paraphrase) "too many people can vote for > something they don't understand and won't have to maintain". > > Asking people to say why they voted the way they did helps explore this: > can people give a cogent reason for their vote? Shall we then also expect people that vote "yes" to explain why they voted for the feature? To see whether they understood what they where voting on? Then we should couple the vote to a comment in the wikinpage and without a comment there's no way to vote. That way all the information would be readily available in the RFC and no one would need to add comments after an RFC was voted upon. Because IMO that information as well as the process that lead to acceptance of the RFC are also important to afterwards make clear why that feature was implememted the way it was. So all RFCs and also all voters would be treated the same. Just my 0.02€ Cheers Andreas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC Process: more productive conversations
On Mon, 25 Mar 2019 at 14:02, Dan Ackroyd wrote: > I don't believe forcing people to explain their votes actually does that. > > It does something quite similar, of forcing people to try to > articulate how the RFC needs to change for them to change their vote > from a no to a yes. At least that is how I have perceived the > intentions of people who have asked for 'no' voters to explain their > vote. > It also ties in with the view previously expressed that we should restrict voting rights because (my paraphrase) "too many people can vote for something they don't understand and won't have to maintain". Asking people to say why they voted the way they did helps explore this: can people give a cogent reason for their vote? Peter
Re: [PHP-DEV] RFC Process: more productive conversations
On Mon, 25 Mar 2019 at 14:02, Dan Ackroyd wrote:
> On Mon, 25 Mar 2019 at 13:30, Rowan Collins
> wrote:
> >
> > One suggestion for an additional section: update the RFC with feedback,
> > particularly if it is withdrawn or rejected.
>
> I think that knowledge could live separately from the RFCs, which is
> why I'm maintaining https://github.com/Danack/RfcCodex
>
> The reasons for doing it separately are:
>
> * the last thing someone wants to do after having their RFC voted down
> is spending more time documenting it.
>
That feels pessimistic to me: is assumes that the author feels unhappy with
the RFC failing, rather than taking on board the feedback. You already have
a section headed "Don't be too put out if people don't like your RFC", and
I think taking on board why people disagreed is a big part of that.
> * some ideas have had multiple RFCs, while other ideas are proposed on
> the list without having a formal RFC. For both scenarios documenting
> why it failed in a single place needs to be elsewhere than an RFC
> page.
>
That's certainly an issue, which I've suggested before in the form of an
"Internals FAQ". However, it somewhat contradicts your previous point:
you're now asking someone to do *even more work* after an RFC is rejected,
to summarise it in a new format, in a new location. Either that's the RFC
author, or it's someone interested enough that they could offer to write it
in the RFC itself.
As RFCs re-raising previous ideas, they can and should link to and explain
their relationship to related RFCs, and this should probably be in the
guidelines if it's not already.
> > It has actually been suggested multiple times that
> > voters *should* justify their votes,
>
> Yes. However that is unlikely to provide a useful conversation.
> Thinking that the RFC is just a terrible idea is always a valid reason
> to vote no. Having people say that "this RFC is terrible" doesn't lead
> to a productive conversation.
>
That's because it's an unhelpful comment. What does "terrible" mean? Other
than "I assume you raised this in bad faith", there is *always* a more
productive explanation than that - "I don't think this fits the
style/purpose/scope of the language", "I think this would encourage/only be
useful for bad practices", etc.
> > so that it's clear whether a future RFC could address the
> > perceived problems,
>
> I don't believe forcing people to explain their votes actually does that.
>
Right, which is why I said I'm on the fence about *forcing* it, but that we
should at least *encourage* it.
> The problem with that is that some RFCs are just fundamentally not
> good and so there isn't any changes that could be made that would make
> the RFC acceptable.
>
> In those scenarios, putting pressure on 'no' voters to say what needs
> to be fixed, is just putting pressure on people to not vote no.
>
I don't think that follows. If the answer to "what would make you change
your mind?" is "nothing", that's still useful feedback - it tells future
RFC authors not to approach the suggestion at all.
> Additionally in some of the RFC discussions we've had, where the
> author has asked for people to explain the 'no' votes, the reasons
> have already been said clearly in the discussion phase.
>
Yes, the important thing is that the different reasons for no votes are
captured, not that the exact counts for each are tallied. It's also a
reason to add a text field to the voting widget: it doesn't invite
responses in the same way a post to the mailing list thread does.
I think a reasonable compromise is to say that voters should mention the
reasons they're voting no if they have not already been mentioned; but that
proposers should assume that votes without a reason are agreeing with
previously stated reasons. That discourages voters assuming proposers can
read their mind ("well, obviously it's bad") but also discourages proposer
pestering and cross-examining voters.
Regards,
--
Rowan Collins
[IMSoP]
Re: [PHP-DEV] RFC Process: more productive conversations
On Mon, 25 Mar 2019 at 13:30, Rowan Collins wrote: > > One suggestion for an additional section: update the RFC with feedback, > particularly if it is withdrawn or rejected. I think that knowledge could live separately from the RFCs, which is why I'm maintaining https://github.com/Danack/RfcCodex The reasons for doing it separately are: * the last thing someone wants to do after having their RFC voted down is spending more time documenting it. * some ideas have had multiple RFCs, while other ideas are proposed on the list without having a formal RFC. For both scenarios documenting why it failed in a single place needs to be elsewhere than an RFC page. > It has actually been suggested multiple times that > voters *should* justify their votes, Yes. However that is unlikely to provide a useful conversation. Thinking that the RFC is just a terrible idea is always a valid reason to vote no. Having people say that "this RFC is terrible" doesn't lead to a productive conversation. > so that it's clear whether a future RFC could address the > perceived problems, I don't believe forcing people to explain their votes actually does that. It does something quite similar, of forcing people to try to articulate how the RFC needs to change for them to change their vote from a no to a yes. At least that is how I have perceived the intentions of people who have asked for 'no' voters to explain their vote. The problem with that is that some RFCs are just fundamentally not good and so there isn't any changes that could be made that would make the RFC acceptable. In those scenarios, putting pressure on 'no' voters to say what needs to be fixed, is just putting pressure on people to not vote no. Additionally in some of the RFC discussions we've had, where the author has asked for people to explain the 'no' votes, the reasons have already been said clearly in the discussion phase. But the RFC author has dismissed those reasons as 'invalid'. Again, trying to force people to justify their reasons, to the satisfaction of the RFC author isn't going to lead to a productive conversation. cheers Dan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC Process: more productive conversations
Den man. 25. mar. 2019 kl. 15.30 skrev Rowan Collins : > > It isn't the responsibility of voters to explain why they're voting no. > > It has actually been suggested multiple times that voters *should* justify > their votes, so that it's clear whether a future RFC could address the > perceived problems, or if similar RFCs are likely to receive the same votes > against. I'm on the fence whether making it a hard requirement is > reasonable, but I don't think we should enshrine the opposite. As a voter and maintainer, I don't really wish to state my opinion on every single vote I do, I think that is too much. I know it is preferable as a maintainer, certainly, however instead I think to be following the proposed style of etiquette, it would be recommended, but not a hard requirement to state your reasoning for a vote. If anything I think we should extend the voting addon for dokuwiki to have such an option for primary voting polls. -- regards, Kalle Sommer Nielsen ka...@php.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC Process: more productive conversations
On Mon, 25 Mar 2019 at 13:04, Dan Ackroyd wrote: > I've written some suggestions on people could have more productive > conversations which I'm going to maintain here > (https://github.com/Danack/RfcCodex/blob/master/rfc_etiquette.md), and > have attached to the end of this email. > Hi Dan, Thanks for putting this together, I think it's a great addition to the current RFC guidance. The only part I can see being controversial is this: > It isn't the responsibility of voters to explain why they're voting no. It has actually been suggested multiple times that voters *should* justify their votes, so that it's clear whether a future RFC could address the perceived problems, or if similar RFCs are likely to receive the same votes against. I'm on the fence whether making it a hard requirement is reasonable, but I don't think we should enshrine the opposite. One suggestion for an additional section: update the RFC with feedback, particularly if it is withdrawn or rejected. If someone comes along with a suggestion that's been discussed before, it's really helpful if we can say "see this page for why it didn't happen last time, and see if you can fix those issues", rather than just "it didn't get very far before, but we can't remember why". This is something I intend to do with my own "locked classes" RFC: I'm probably going to withdraw it because I don't have time to rework it, but will try to summarise where a new RFC could pick things up. Regards, -- Rowan Collins [IMSoP]
