[RFC] [Discussion] Third-party editing of RFCs

php.internals

Sara Golemon

10 years ago
https://wiki.php.net/rfc/rfc.third-party-editing Let's make RFCs more useful before AND after voting! -Sara

Mike Willbanks

10 years ago
On Thu, May 12, 2016 at 12:33 PM, Sara Golemon <pollita@php.net> wrote:
> https://wiki.php.net/rfc/rfc.third-party-editing > > Let's make RFCs more useful before AND after voting! >
Yes please! It certainly would make it far easier to see the arguments for and against and have a history of said arguments rather than searching the mailing list and going through 100+ responses across 5 threads and weeding through them.

Robert Williams

10 years ago
This would be great if everyone just wanted to state their stance and be done with it. It reminds me of the election pamphlets that my state sends out to inform voters of what the upcoming ballet measures are and what various folks’ for/against arguments are. But those arguments are collected in advance and there is only a single edition printed, so there are no direct responses. I’m not sure how well this format would work with the back-and-forth that usually happens in RFC discussions. Will folks need to summarize (and respond to) all the arguments they want to address in their addition, and keep updating it as new arguments come in to which they want to respond? Will they be able to link to others’ comments and respond to them that way? And if they can link, what will stop these sections from becoming piles of spaghetti? Would folks wait until near the end of the discussion period to make their additions to avoid repeat visits, and how would that affect the discussion? -Bob

Sara Golemon

10 years ago
On Thu, May 12, 2016 at 1:32 PM, Robert Williams <rewilliams@thesba.com> wrote:
> It reminds me of the election pamphlets that my state sends > out to inform voters of what the upcoming ballet measures are and what > various folks’ for/against arguments are. >
I was literally looking at said pamphlet when the thought occurred to me. :)
> But those arguments are collected > in advance and there is only a single edition printed, so there are no > direct responses. I’m not sure how well this format would work with the > back-and-forth that usually happens in RFC discussions. >
I don't imagine this piece replacing "live" discussions, nor would I expect that it would completely remove repetition of arguments. It's just meant to help organize arguments pro/con in a single, easily referenced place.
> And if they can link, what will stop these sections from becoming piles of spaghetti? >
Self-interest. I expect it's fairly well agreed that concise arguments tend to be more effective for simple virtue of the fact that they'll be read. Those voter pamphlets recognize this too and keep their statements to, at most, one page. I've updated my pipe-operator RFC to reflect what I imagine this might look like: https://wiki.php.net/rfc/pipe-operator#third-party_arguments
> Would folks wait until near the > end of the discussion period to make their additions to avoid repeat visits, > and how would that affect the discussion? >
I would probably update as new arguments are raised. And I would hope it would effect the discussion for the positive as opinions wouldn't need to be restated over and over again, and when it comes times to vote, those doing the voting could refresh their feelings on each argument. -Sara

Rowan Collins

10 years ago
Sara Golemon wrote:
> https://wiki.php.net/rfc/rfc.third-party-editing > > Let's make RFCs more useful before AND after voting!
> I would hope > it would effect the discussion for the positive as opinions wouldn't > need to be restated over and over again, and when it comes times to > vote, those doing the voting could refresh their feelings on each > argument.
+1 I'm a big fan of summarising and synthesising discussions. Mailing list archives may be particularly fiddly, but even the best forum software can't fix the fact that conversations ramble and repeat and take a long time to re-read. It might be worth having a few quick guidelines (without getting too lawyerly) - encourage bulleted lists, or paragraphs of 2 sentences at most; link to mailing archives where particularly key points or examples were raised. If it's kept as a quick "primer" on the main arguments, then there's less temptation to repeat the actual debate in competing comments on the page. I'm also not sure about the name; I'm not sure who the "second party" is for these to be "third-party", and "argument" has unfortunate connotations, even though they're not meant here. Perhaps just "Points raised during discussion"? Now to register a wiki account, so I can add some "3rd-party arguments" to the "3rd-party editing" RFC... ;) Regards,
-- Rowan Collins [IMSoP]

Stas Malyshev

10 years ago
Hi!
> https://wiki.php.net/rfc/rfc.third-party-editing > > Let's make RFCs more useful before AND after voting!
I like the idea, though I would suggest some limit on how big each argument should be (maybe informal recommendation) to not turn that section into a copy of the ML discussion.
-- Stas Malyshev smalyshev@gmail.com

Sara Golemon

10 years ago
On Thu, May 12, 2016 at 4:37 PM, Stanislav Malyshev <smalyshev@gmail.com> wrote:
>> https://wiki.php.net/rfc/rfc.third-party-editing >> >> Let's make RFCs more useful before AND after voting! > > I like the idea, though I would suggest some limit on how big each > argument should be (maybe informal recommendation) to not turn that > section into a copy of the ML discussion. >
Good point, I've updated the RFC slightly to reflect a recommended style of concise summaries, possibly as bullet point lists. -Sara

François Laupretre

10 years ago
Le 12/05/2016 à 19:33, Sara Golemon a écrit :
> https://wiki.php.net/rfc/rfc.third-party-editing > > Let's make RFCs more useful before AND after voting! > > -Sara >
As RFC author, what should I do with irrelevant arguments against my RFC ? Should I add a reply ? More generally, I don't like the idea that anybody else can add anything to my RFC. I agree that, ideally, the reactions of the ML should be summarized somewhere but the question is : WHO will summarize ? Ideally, we would need an independant 3rd party, but we don't have it. So, the best solution, IMO, is still to let the author summarize the ML discussion in his RFC. Regards François

Rowan Collins

10 years ago
On 13/05/2016 11:07, François Laupretre wrote:
> Le 12/05/2016 à 19:33, Sara Golemon a écrit : >> https://wiki.php.net/rfc/rfc.third-party-editing >> >> Let's make RFCs more useful before AND after voting! >> >> -Sara >> > > As RFC author, what should I do with irrelevant arguments against my RFC > ? Should I add a reply ? More generally, I don't like the idea that > anybody else can add anything to my RFC.
In my opinion, the notion of "owning" an RFC is not always helpful - we're here to work together to come up with the best solution, not to compete for kudos or defend a fixed position. That said, I recognise that the main body of the RFC benefits from having an identified "lead editor", so it stays consistent. If this section is intended as a collaborative summary of the discussion, then I would say you would have no more right or responsibility than anyone else to police it on "your" RFC (and no less, either). If somebody adds something that is genuinely irrelevant (e.g. based on a simple misunderstanding of the RFC) then somebody else (*anyobdy* else) could remove it. However, if it's just that you don't think a particular argument is subjectively valid, then the fact that someone holds a contrary opinion is a useful piece of information to the reader, and should stay. Think of it like a comment section, "the opinions below are not necessarily those of the RFC's sponsors". Regards, Rowan Collins [IMSoP]

Davey

10 years ago
On Fri, May 13, 2016 at 3:30 PM, Rowan Collins <rowan.collins@gmail.com> wrote:
> On 13/05/2016 11:07, François Laupretre wrote: > >> Le 12/05/2016 à 19:33, Sara Golemon a écrit : >> >>> https://wiki.php.net/rfc/rfc.third-party-editing >>> >>> Let's make RFCs more useful before AND after voting! >>> >>> -Sara >>> >>> >> As RFC author, what should I do with irrelevant arguments against my RFC >> ? Should I add a reply ? More generally, I don't like the idea that >> anybody else can add anything to my RFC. >> > > > In my opinion, the notion of "owning" an RFC is not always helpful - we're > here to work together to come up with the best solution, not to compete for > kudos or defend a fixed position. That said, I recognise that the main body > of the RFC benefits from having an identified "lead editor", so it stays > consistent. > > If this section is intended as a collaborative summary of the discussion, > then I would say you would have no more right or responsibility than anyone > else to police it on "your" RFC (and no less, either). > > If somebody adds something that is genuinely irrelevant (e.g. based on a > simple misunderstanding of the RFC) then somebody else (*anyobdy* else) > could remove it. However, if it's just that you don't think a particular > argument is subjectively valid, then the fact that someone holds a contrary > opinion is a useful piece of information to the reader, and should stay. > > Think of it like a comment section, "the opinions below are not > necessarily those of the RFC's sponsors".
Perhaps just split it out into a separate document that is concurrent to the RFC… - Davey

François Laupretre

10 years ago
Le 13/05/2016 à 15:30, Rowan Collins a écrit :
> If somebody adds something that is genuinely irrelevant (e.g. based on a > simple misunderstanding of the RFC) then somebody else (*anyobdy* else) > could remove it.
Maybe I am not candid enough but do you imagine what it could become on a controversial RFC like STH ? What does 'genuinely irrelevant' mean ? Will you accept that someone deletes your comment because he finds it 'genuinely irrelevant' ? Of course not. So, we'll end up with a system where anybody can write anything and nothing can be removed. IMHO, we touch the limit of what can be done with a bare wiki. Another way to solve this need would be to authorize voting as soon as discussion starts and allow an explanation comment to be associated with each vote. People could modify their vote and the associated comment while discussion runs, and it would be easy at any time to get a snapshot of the current trend and a resume of the raised arguments. This would also allow RFC authors to know better why people were voting the way they did, something that was requested several times in the past. Unfortunately, I don't know if we can associate a free comment with the voting tool we're using. This could require writing a new vote app. Regards François

Rowan Collins

10 years ago
On 13/05/2016 15:26, François Laupretre wrote [not in quite this order, I hope I haven't changed the meaning by grouping your sentences differently]:
> Le 13/05/2016 à 15:30, Rowan Collins a écrit : >> If somebody adds something that is genuinely irrelevant (e.g. based on a >> simple misunderstanding of the RFC) then somebody else (*anyobdy* else) >> could remove it. > > What does 'genuinely irrelevant' mean ? > Will you accept that someone deletes your comment because he finds it > 'genuinely irrelevant' ? Of course not.
No, I think deleting points would be very rare, that's why I gave a strongly qualified definition of "genuinely irrelevant". You were the one that raised the notion of "irrelevant" comments, what definition did *you* have in mind? However, I *would* expect people to edit the wording of a point I added if it wasn't clear, or if it could be put more succinctly.
> Maybe I am not candid enough but do you imagine what it could become on > a controversial RFC like STH ?So, we'll end up with a system > where anybody can write anything and nothing can be removed. IMHO, we > touch the limit of what can be done with a bare wiki.
Actually, given the volume of discussion on STH, I would have welcomed an attempt to summarise the main points that had been raised, because I simply didn't have time to read all the mails on the subject, and had to give up trying. And yes, such a summary would have been large (maybe in that case a sub-page would work better than a section, as Davey suggests), but think of it as proportional to the amount of mail discussion. If the archive of the mailing list threads covers 100 pages of A4, a summary covering one page of A4 is still an incredibly useful resource. I mentioned in a previous message encouraging links to list archives. In my mind, these sections should not attempt to *persuade* the reader, or to demonstrate the importance of a particular point, they should attempt to *inform* the reader that a point has been raised.
> Another way to solve this need would be to authorize voting as soon as > discussion starts and allow an explanation comment to be associated with > each vote. People could modify their vote and the associated comment > while discussion runs, and it would be easy at any time to get a > snapshot of the current trend and a resume of the raised arguments.
This makes it all too personal, in my opinion. As I said before, I think we need to encourage the view that RFCs are a collaborative process, not an adversarial one, and "I intend to vote against because of X" is very different from "I like this, but one downside I see is X". The points being discussed might be addressed in future edits of the main RFC text, or they might be tradeoffs that are need considering, but everybody voting decides are worth it on balance. Somebody might edit acting as "Devil's Advocate", summarising points they don't necessarily agree with, but have seen expressed. When somebody comes to vote, the "Discussion Summary" (possible better name for the section / sub-page?) would prompt them to consider the points that had been raised. Regards, Rowan Collins [IMSoP]

Sara Golemon

10 years ago
On Fri, May 13, 2016 at 7:26 AM, François Laupretre <francois@php.net> wrote:
> Le 13/05/2016 à 15:30, Rowan Collins a écrit : >> >> If somebody adds something that is genuinely irrelevant (e.g. based on a >> simple misunderstanding of the RFC) then somebody else (*anyobdy* else) >> could remove it. >> > > Maybe I am not candid enough but do you imagine what it could become on a > controversial RFC like STH ? What does 'genuinely irrelevant' mean ? Will > you accept that someone deletes your comment because he finds it 'genuinely > irrelevant' ? Of course not. So, we'll end up with a system where anybody > can write anything and nothing can be removed. IMHO, we touch the limit of > what can be done with a bare wiki. >
I want to start by acknowledging this totally legitimate concern. We can get heated sometimes, and I wouldn't put it past one or more of us (maybe me?) to deface someone else's argument out of spite. BUT, these Wikis have a history log. And if John Smith removes or maliciously modifies an argument I've introduced, I'll notice, and I'll be the first to ask for a public explanation of why he chose to do so. Maybe they were right to do so, maybe they weren't. Regardless, that'll put social pressure on one of us to shape up. Similarly, anyone spamming RFCs with irrelevant arguments can be brought to task on by anyone else for doing so. This isn't actually much different than what we have now, since we all have the (technical) rights to edit anyone's RFC. I've done so on a few occasions, without asking the author, to fix minor wiki formatting and typo errors. The extra step being suggested is just explicit permission to do so in one specific subsection with an implicit expectation of adding to the conversation.
> Another way to solve this need would be to authorize voting as soon as > discussion starts and allow an explanation comment to be associated with > each vote. People could modify their vote and the associated comment while > discussion runs, and it would be easy at any time to get a snapshot of the > current trend and a resume of the raised arguments. This would also allow > RFC authors to know better why people were voting the way they did, > something that was requested several times in the past. Unfortunately, I > don't know if we can associate a free comment with the voting tool we're > using. This could require writing a new vote app. >
Even if not done in a pre-vote period, I would love the OPTION of adding an explanation for votes. I'm a bit more on the fence about declaring voting intention ahead of time though. -Sara

Stas Malyshev

10 years ago
Hi!
> BUT, these Wikis have a history log. And if John Smith removes or > maliciously modifies an argument I've introduced, I'll notice, and > I'll be the first to ask for a public explanation of why he chose to > do so. Maybe they were right to do so, maybe they weren't. > Regardless, that'll put social pressure on one of us to shape up. > Similarly, anyone spamming RFCs with irrelevant arguments can be > brought to task on by anyone else for doing so.
I agree. The fact that we are having the RFCs is a proof that this strategy works well enough - all the sides of the RFC have commit access, so we could just be committing the code into the repo and reverting and making the mess out of it. But we aren't because we realize that's not how the things should be done. In the same way, we can agree about how the things are done inside RFCs, and while we definitely will have argument and controversy, I have full confidence we will be able to manage it within reasonable bounds - because we already are.
> Even if not done in a pre-vote period, I would love the OPTION of > adding an explanation for votes. I'm a bit more on the fence about > declaring voting intention ahead of time though.
This can be - and is - done in the list discussion. I don't see much value in having permanent record of voting intent on the RFC beyond the vote itself. OTOH, this is roughly how the voting is done in Wikipedia and sister projects - you place a vote (either positive, negative or you can also abstain) and usually a short description. Which can be as short as "agree with N." or "I don't think this is right" or much longer and result in a discussion and sometimes even change of vote. But usually long discussion in votes is discouraged. It is also not easy to keep track of it because whole discussions on wiki implementation is meh. I do not know if this system is superior to what we have - very well may be not - but just bringing it forward that such system exists and if interested, you can observe it in action.
-- Stas Malyshev smalyshev@gmail.com

Joe Watkins

10 years ago
Evening, I like the idea that we should pay more attention to setting out arguments, for and against. Still, I regard editing someone else's work as poor form. Introducing a way to do that, and relying on social pressure to keep everyone in check is not a good long term plan ... sounds great, until someone actually does make an edit that the original author vehemently disagrees with. Can't we just require the section to be included by the original author(s) ? Cheers Joe On Fri, May 13, 2016 at 7:36 PM, Stanislav Malyshev <smalyshev@gmail.com> wrote:

Sara Golemon

10 years ago
On Fri, May 13, 2016 at 1:56 PM, Joe Watkins <pthreads@pthreads.org> wrote:
> Still, I regard editing someone else's work as poor form. > > Introducing a way to do that, and relying on social pressure to keep > everyone in check is not a good long term plan ... sounds great, until > someone actually does make an edit that the original author vehemently > disagrees with. >
This is why I defined the TPE RFC to scope that permission SOLELY to the arguments section. I agree that the rest of the document should be considered "owned" by the original author. Would taking a page out of Wikipedia by having the notion of "Talk" pages make more sense, perhaps?
> Can't we just require the section to be included by the original > author(s) ? >
We can, and I'd settle for that as a first step, but as the RFC states, it doesn't do justice to the "Against" arguments to rely on someone who is, by definition, in favor of the proposal to summarize all arguments convincingly. -Sara

Joe Watkins

10 years ago
Evening,
> This is why I defined the TPE RFC to scope that permission SOLELY to
the arguments section. I get that, but it doesn't make enough of a difference, in my opinion.
> We can, and I'd settle for that as a first step, but as the RFC
states, it doesn't do justice to the "Against" arguments to rely on someone who is, by definition, in favor of the proposal to summarize all arguments convincingly. I like little steps, less likely to fall over :) If we are going to apply social pressure to change anything, it should be to eradicate the tendency to marry before voting ... The wiki is exclusive, the vast majority of the community who are free to come and argue their case, don't even have the ability to edit the wiki. Talking about doing an argument justice, by allowing a select few to edit the work of others, doesn't make sense to me. When opcache was merged it was ignored by every RFC, even though it's very difficult to do anything in /Zend without impacting opcache. All it took to get people to consider the impact was adding the section late one night (I done it). Nobody ever bothers to remove that section, and if they are able, they fill it in (or are told how to fill it in). The objectives seem to be fulfilled by just adding the section into the template, and formally requiring that it be maintained during discussion. Cheers Joe On Fri, May 13, 2016 at 10:32 PM, Sara Golemon <pollita@php.net> wrote:

Yasuo Ohgaki

10 years ago
On Fri, May 13, 2016 at 2:33 AM, Sara Golemon <pollita@php.net> wrote:
> https://wiki.php.net/rfc/rfc.third-party-editing > > Let's make RFCs more useful before AND after voting!
Sure. I'll adopt this from now on regardlessly. Regards,
-- Yasuo Ohgaki yohgaki@ohgaki.net

Yasuo Ohgaki

10 years ago
Hi Sara, On Fri, May 13, 2016 at 2:33 AM, Sara Golemon <pollita@php.net> wrote:
> https://wiki.php.net/rfc/rfc.third-party-editing > > Let's make RFCs more useful before AND after voting!
Could you add performance section? I would like to know performance impact always, but not all RFCs include it. Thanks.
-- Yasuo Ohgaki yohgaki@ohgaki.net