FAQ
https://wiki.php.net/rfc/rfc.third-party-editing

Let's make RFCs more useful before AND after voting!

-Sara

Search Discussions

  • Mike Willbanks at May 12, 2016 at 7:16 pm

    On Thu, May 12, 2016 at 12:33 PM, Sara Golemon 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.

    -Sara

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Robert Williams at May 12, 2016 at 8:32 pm
    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 at May 12, 2016 at 10:47 pm

    On Thu, May 12, 2016 at 1:32 PM, Robert Williams 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 at May 12, 2016 at 11:19 pm

    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]
  • Stanislav Malyshev at May 12, 2016 at 11:38 pm
    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 at May 13, 2016 at 1:44 am

    On Thu, May 12, 2016 at 4:37 PM, Stanislav Malyshev 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 at May 13, 2016 at 10:07 am

    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 at May 13, 2016 at 1:32 pm

    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 Shafik at May 13, 2016 at 2:22 pm

    On Fri, May 13, 2016 at 3:30 PM, Rowan Collins 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 at May 13, 2016 at 2:26 pm

    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 at May 13, 2016 at 2:48 pm
    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 at May 13, 2016 at 6:06 pm

    On Fri, May 13, 2016 at 7:26 AM, François Laupretre 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
  • Stanislav Malyshev at May 13, 2016 at 6:37 pm
    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 at May 13, 2016 at 8:56 pm
    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 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

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php
  • Sara Golemon at May 13, 2016 at 9:32 pm

    On Fri, May 13, 2016 at 1:56 PM, Joe Watkins 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 at May 13, 2016 at 10:01 pm
    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 wrote:
    On Fri, May 13, 2016 at 1:56 PM, Joe Watkins 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
  • Yasuo Ohgaki at May 13, 2016 at 11:16 am

    On Fri, May 13, 2016 at 2:33 AM, Sara Golemon 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 at May 15, 2016 at 1:49 am
    Hi Sara,
    On Fri, May 13, 2016 at 2:33 AM, Sara Golemon 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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedMay 12, '16 at 5:33p
activeMay 15, '16 at 1:49a
posts19
users9
websitephp.net

People

Translate

site design / logo © 2018 Grokbase