# RFC Process: more productive conversations - Thread: https://externals.io/message/104923 - Original archive: https://news-web.php.net/php.internals/104923 - Started by Dan Ackroyd on 2019-03-25T13:04:17+00:00 - Messages: 11 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #104923 — Dan Ackroyd — 2019-03-25T13:04:17+00:00 URL: https://externals.io/message/104923#104923 Hi Internals, A little while ago Zeev suggested that it was time to update the RFC process to make it more fit for purpose. As part of that conversation I would like to suggest some 'etiquette' around RFC discussions. PHP internals has a reputation for being 'toxic'. While I don't think it's as bad as some people try to suggest it is, we could make RFC discussions be more productive and less emotionally draining by people being more careful how they interact with each other on this list. 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. These would be mostly suggestions for keeping conversations rather than hard rules, as most of them involve gray areas, which couldn't and shouldn't be enforced with hard rules. I'm sending this list now, but the full conversation might be better to have as a part of a full review of the RFC process. However, there are a few that I think we should discuss sooner rather than later. # Better process for handling suggestions that are never likely to pass Recently, someone suggested adding the capability for PHP to print strings that are automatically terminated with a new line. Putting it mildly, that conversation didn't go well, as by the end of it people were swearing at each other on the list. PHP internals could do with a better process for giving negative feedback an idea without someone having to go through the whole RFC process. I don't have a good suggestion for how to do this. Does anyone else? # People other than the author announcing RFCs on internals Through possibly a series of errors, someone who was not the author started a thread on internals for an RFC right after it had been created, while it was still in draft status. The site wiki.php.net/rfc is a tool that is meant to allow people to draft RFCs and share the idea with other people who want to work on the RFC before it is a polished idea, and before it is ready to be presented to the world. Having someone other than the RFC author announce the RFC on internals before the author thinks the RFC is ready for comment, is "not okay". If you discuss an RFC on internals before the author thinks the RFC is ready to be discussed, the only thing that could achieve is to make the conversation less productive. If you want to influence how the RFC is drafted, it can appropriate to reach out to the RFC author, and offer to help them. # Contacting RFC authors should go through PHP internals list Drafting RFCs and pushing them through internals is an exhausting process. Several PHP contributors have suddenly stopped contributing to the project after successfully getting an RFC passed, due to them being entirely fed up. One of the things that quickly becomes tiresome is people contacting the RFC author (or voters) through communication channels (other than the PHP internals list), particularly when what they are going to say is either negative or even just based on not understanding part of the RFC. There is a difference between giving positive feedback and negative feedback. And there is a difference between giving feedback to someone you have communicated with many times before, and contacting someone for the first time. It's hard to draw an exact line for which communication is fine to go off-list, and which should stay on list. But here are some examples: "You are awesome for writing such an amazing RFC" - fine to send off-list. "I found some typos in the RFC" - probably fine to send off-list, particularly if you communicate with the RFC author already. "Please can you answer this question about the RFC" - possibly fine to send off-list, but only if you know the RFC author already. "The RFC is a terrible idea for these reasons" - should only be sent via the list. cheers Dan Below is the full list of suggestions. As I said, I'll maintain it at https://github.com/Danack/RfcCodex/blob/master/rfc_etiquette.md until a more formal RFC process discussion kicks off. ## Don't publicise draft work The site wiki.php.net/rfc is a tool that is meant to allow people to draft RFCs and share the idea with other people who want to work on the RFC before it is a polished idea, and before it is ready to be presented to the world. Having someone other than the RFC author announce the RFC on internals before the author thinks the RFC is ready for comment, is "not okay". If you discuss an RFC on internals before the author thinks the RFC is ready to be discussed, the only thing that could achieve is to make the conversation less productive. If you want to influence how the RFC is drafted, it is appropriate to reach out to the RFC author, and offer to help them. ## Do open new RFCs rather than re-use existing documents. When revisiting ideas, and the previous version of an RFC hasn't been discussed in a long time (e.g. more than 6 months) or when a previous version was declined by vote, it is preferable to open new documents on the wiki, rather than re-use existing documents. We have rules in place about when RFCs are allowed to be put into voting. If a RFC document has been re-used there could be some confusion about when it is allowed to be put to a vote. Additionally, leaving the previous RFC document intact, with the results of a vote if one was taken, leaves a clearer document trail than if the document has been recycled. To put it another way - in general the status of an RFC should not be moved backwards to an earlier status. In practice there will be times when people accidentally open the voting too early, or some serious problem is found with an RFC during the voting phase, in which cases it's fine to move the status back until the problem is fixed. But in general leaving each RFC document with a clear history of what happened to that RFC makes it easier to understand past discussions. ## Don't volunteer other people for huge amounts of work The response to some RFCs has been to suggest that the RFC doesn't cover enough scope, and that the RFC author should make the RFC be a lot bigger. While that sounds reasonable on the surface, the amount of time people have to work on PHP RFCs is often limited. Having someone say "thanks for volunteering, but now I want you to do a lot more work than you volunteered for" is a subtle way of preventing RFCs from being implemented. In some cases the suggestion to make the RFC be bigger has been well-intentioned, and so the damage has been accidental. In other cases, it would seem that the suggestion that the RFC needs to be a lot bigger or not done at all has come from someone who doesn't want the RFC to pass, which could be interpreted as deliberately making it more difficult for the RFC to pass. It's okay for RFCs to be small in scope, so long as they are self-contained. It would only be appropriate to say that the RFC needs to be bigger if it would otherwise leave new inconsistencies in the language that would need to be resolved before the next release. ## Do try to talk about the problem before talking about possible solutions Some RFCs don't make it clear what problem it is they are trying to solve before proposing a solution. This leads to the discussions being not as productive as if the problem was introduced first. Some people might disagree on what the exact problem is, or disagree that it even is a problem that needs solving to begin with. If people can't clearly understand that there is a problem that needs solving, then the discussion about possible solutions is going to be incredibly heated, with people not understanding the other side. Some people might offer different solutions to the same set of problems. If the original RFC has skipped over defining the problem clearly, then it makes it a lot harder for people to suggest alternative solutions to the same problem. Additionally, although some sets of problems may be closely related, by talking about the problems clearly, they might be broken up into separate problems to be solved by separate RFCs. ## Don't say that other people's use cases are invalid The response to some RFCs is disappointing. Rather than accepting other people as being individuals with different priorities and motivations, some people on internals have responded with "I don't want to use this proposed feature, therefore I don't think any people should use this feature". When you have someone saying "I want this feature", and your response is "I don't believe you actually want that feature", then you've crossed a line from being reasonable to arguing based on Solipsism, which is not going to lead to a productive discussion. It's still okay to question how many people would want or actually use a feature, but just straight refusing to believe that anyone could find something useful doesn't give a productive discussion. ## Do try to improve RFCs Even if you disagree with an RFC, it is good to try suggest improvements to it, if you can see them, rather than just criticising the RFC. If the vote passes, and the RFC contains your suggested improvement - congratulations, you've helped make PHP better. If the vote doesn't pass, even though the RFC was as good as it could be, then it will be clear to anyone who might think about reopening the RFC that it needs to be dramatically improved or take another approach for it to have a chance to be passed, rather than just having a small tweak. ## Don't be too put out if people don't like your RFC It is quite natural for an RFC author to think that the RFC the are proposing is clearly a good idea - why else would they be proposing it? It's also natural for them to hope that everyone else will think it's a good idea also. However it is also entirely possible for people to have rational reasons to disagree with a proposal. Maybe some people haven't experienced the problem the RFC is trying to solve, and so they don't think the problem is even one that needs solving. Maybe they have experienced in a different language what is being proposed for PHP, and they didn't like using it in that language, so they find it hard to see why it would be good for PHP. Whatever the reason, when people respond with something less than overwhelming support for the idea, they aren't doing it out of malice, they're doing it because they also want PHP to be the best possible language it can be - they just disagree about what that means. ## Do take your time to respond to emails For a couple of reasons, it is appropriate to take time to read and compose emails about RFCs; much longer than you spend writing emails on other subjects. > "I'm sorry I wrote you such a long letter; I didn't have time to write a short one. Emails that are sent on PHP internals that discuss RFCs are read by hundreds if not thousands of people. Writing concisely will save a lot of other people's time. It is also far more likely that people will read and understand your email if it is short than if you write long emails. Additionally, unless someone was just discussing trivial issues (such as a typo in the RFC) it is appropriate to think about and digest what they were saying, rather than giving a response based on your first thoughts. ## Don't try to demand that people justify their opinions It is the role of RFC authors to convince other people that an RFC is definitely a good idea, and that people should vote yes on it. People might have many reasons to vote no, e.g. not convinced the problem the RFC addresses is one that needs solving, not convinced the problem is solved in the right way, not convinced that the solution is a correct one. Some of these feelings about why a proposal doesn't deserve a 'yes' vote are hard to express. It isn't the responsibility of voters to explain why they're voting no. ## Don't shout down other people Even if you don't like an RFC being discussed, it is more appropriate to ignore that thread, rather than asking people in the thread to stop talking about an idea you don't like. # Contacting RFC authors should go through PHP internals list Drafting RFCs and pushing them through internals is an exhausting process. Several PHP contributors have suddenly stopped contributing to the project after successfully getting an RFC passed, due to them being entirely fed up. One of the things that is tiresome is people contacting the RFC author through communication channels (other than the PHP internals list), particularly when what they are going to say is either negative or even just based on not understanding part of the RFC. There is a difference between giving positive feedback and negative feedback. And there is a difference between giving feedback to someone you have communicated with many times before, and contacting someone for the first time. It's hard to draw an exact line of where communication is fine to go off-list, and where it should stay on list. But here are some examples: "You are awesome for writing such an amazing RFC" - fine to send off-list. "I found some typos in the RFC" - probably fine to send off-list, particularly if you communicate with the RFC author already. "Please can you answer this question about the RFC" - possibly fine to send off-list, but only if you know the RFC author already. "The RFC is a terrible idea for these reasons" - should only be sent via the list. --- ## #104924 — Rowan Collins — 2019-03-25T13:30:25+00:00 URL: https://externals.io/message/104923#104924 > 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] --- ## #104925 — Kalle Sommer Nielsen — 2019-03-25T13:36:54+00:00 URL: https://externals.io/message/104923#104925 Den man. 25. mar. 2019 kl. 15.30 skrev Rowan Collins : > > […] > > 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 kalle@php.net --- ## #104927 — Dan Ackroyd — 2019-03-25T14:01:47+00:00 URL: https://externals.io/message/104923#104927 > > 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 --- ## #104929 — Rowan Collins — 2019-03-25T14:38:17+00:00 URL: https://externals.io/message/104923#104929 > On Mon, 25 Mar 2019 at 13:30, Rowan Collins > wrote: > > […] > > 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. > > […] > > 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. > > […] > > 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] --- ## #104931 — Peter Bowyer — 2019-03-25T14:39:20+00:00 URL: https://externals.io/message/104923#104931 > 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 --- ## #104936 — Andreas Heigl — 2019-03-25T15:24:27+00:00 URL: https://externals.io/message/104923#104936 > Am 25.03.2019 um 15:39 schrieb Peter Bowyer : > > > […] > > 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 --- ## #104941 — Peter Bowyer — 2019-03-25T15:56:22+00:00 URL: https://externals.io/message/104923#104941 > 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 --- ## #104948 — Ben Ramsey — 2019-03-25T19:28:03+00:00 URL: https://externals.io/message/104923#104948 > > > > > > […] > > Yes. > > > > […] > > 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 --- ## #104955 — Peter Bowyer — 2019-03-26T08:01:21+00:00 URL: https://externals.io/message/104923#104955 > 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 --- ## #104958 — Chase Peeler — 2019-03-26T13:25:48+00:00 URL: https://externals.io/message/104923#104958 On Tue, Mar 26, 2019 at 4:02 AM Peter Bowyer wrote: > > > > […] > some > > […] > > 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. > > > > […] > > 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 chasepeeler@gmail.com