https://wiki.php.net/rfc/rfc.third-party-editing
Let's make RFCs more useful before AND after voting!
-Sara
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.
-Sara
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
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
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]
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
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
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
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]
On Fri, May 13, 2016 at 3:30 PM, Rowan Collins rowan.collins@gmail.com
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
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
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]
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
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
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:
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
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
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 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
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
Hi Sara,
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