Re: [Errata-design] sanity notwithstanding...

[Stephen Farrell <[e-mail]>]

On 28/12/14 20:06, Pete Resnick wrote:
> On 12/28/14 1:57 PM, Stephen Farrell wrote:
>> On 28/12/14 19:50, Pete Resnick wrote:
>>
>>   
>>> I like Stephen's model in principle, but I think it presumes a different
>>> world than the one we live in. We have chatted on occasion about doing
>>> standards in a more "githubby" way, where we would develop them in a
>>> more fluid repository and for which changes are not such a big deal. I'm
>>> all for that. But right now, we are in a world where RFCs are immutable
>>> documents that are on the other side of a solid (though not very high)
>>> wall from where we do the development of them, with scant little way for
>>> that more fluid style of work. Since we're not undertaking changing the
>>> base, I don't think it makes sense to changing the model that
>>> drastically for the errata just yet.
>>>
>>> I'm OK with an generic "commentary" wiki without authority, but I still
>>> want some way to take editorial nonsense and "vote them off the island"
>>> to send them over to the RFC Editor to stick with the immutable
>>> document. Similarly, things that get voted as "vitally important" should
>>> also get flagged to the RFC Editor to put a marker in/with the immutable
>>> document so that people get notice of it. I'm OK with all of that (and
>>> other comments) remaining in the wiki.
>>>
>>> But let's not try to get rid of the wall just now, since I fear that we
>>> will never converge.
>>>      
>> I don't get your concern Pete, what bad thing might happen if we took
>> the route I outlined?
>>    
> 
> I think what I'm proposing is actually simply an addition to your
> proposal rather than something that is wrong with it: Have the wiki (or
> whatever other tool), have the responsibility for reviewing what's in
> there be a community thing, have "voting up/down" on whether something
> is important or useless. All good. Just add on that when certain kinds
> of results occur in that "voting" (in particular, the community votes
> something "editorial nonsense" or "vitally important fix for a bug"),
> have the RFC Editor do what they will to keep track of those in their
> immutable repository. The RFC Editor seems to care about the
> "unimportant" (from our technical perspective) editorial things, and I
> think we all care that nobody goes to the RFC Editor version of the
> document without seeing the really important fixes for bugs called out.

Pete and I chatted on IM and our positions are closer than I thought.

S.

> 
>> In case it helps, I'd be fine to define the set of folks allowed vote
>> comments up/down as being those with a datatracker a/c, but I'm not sure
>> if that touches on your concern.
>>    
> 
> Peachy, but orthogonal to the above.
> 
> pr
> 
>>> On 12/28/14 1:26 PM, Stephen Farrell wrote:
>>>
>>>     
>>>> On 28/12/14 18:42, Barry Leiba wrote:
>>>>
>>>>       
>>>>> Pete has stated my position very well indeed.
>>>>>
>>>>>          
>>>> Close to mine too. But not quite identical.
>>>>
>>>> I'd differ in that I think we don't need to classify what
>>>> kinds of commentary an RFC might attract ahead of time,
>>>> and it'd be a mistake to try as we'd get it wrong. So the
>>>> concept of marking comments as editorial, technical, change
>>>> request, etc is broken. I'd also prefer if we can have the
>>>> community establish which comments are important and not
>>>> have to depend on, or bother, anyone in "authority." Voting
>>>> up/down should work just fine for all kinds of comments I
>>>> reckon. Those that are really important will bubble up and
>>>> get known.
>>>>
>>>> Lastly, there are also many unimportant RFCs for which I
>>>> don't think any of us ought spend time, regardless of whether
>>>> or not a comment identifies a real interop issue. For example,
>>>> I don't believe there are any implementations of RFC 3185,
>>>> (I'm a co-author, it was a tool that would have been needed
>>>> for a road-not-taken by Diameter,) and there don't appear to
>>>> be any interesting citations to it either from RFCs, or
>>>> according to google scholar -  so we ought not bother to do
>>>> anything at all if someone files an erratum or any kind of
>>>> comment on that - and if the idea in that RFC ever does get
>>>> important again then we can go back and fix our comment
>>>> dispositions later anyway.
>>>>
>>>> The above assumes a basic level of comment-spam handling
>>>> but that can also be somewhat automated, e.g. there's an
>>>> anti-spam plugin for wordpress that is their most popular
>>>> plugin. I don't know what that does, but I'll bet a beer we
>>>> can get a long way with such existing tooling, whether
>>>> that one or some other.
>>>>
>>>> Cheers,
>>>> S.
>>>>
>>>>
>>>>
>>>>       
>>>>> Barry
>>>>>
>>>>> On Sun, Dec 28, 2014 at 12:05 PM, Pete Resnick
>>>>> <[e-mail]>   wrote:
>>>>>
>>>>>         
>>>>>> On 12/23/14 1:04 PM, Stephen Farrell wrote:
>>>>>>
>>>>>>           
>>>>>>> The part I want to go away is that each posted erratum consumes
>>>>>>> effort for folks other than the poster. (Incl. me:-)
>>>>>>>
>>>>>>>              
>>>>>> A slight addendum to this, with which Stephen may agree or disagree:
>>>>>>
>>>>>> I don't want errata to consume time and effort for folks other than
>>>>>> those
>>>>>> who want to spend time and effort on it (including the poster).
>>>>>>
>>>>>> That is:
>>>>>>
>>>>>> - I don't care about pure typographical errors. I'm pretty sure
>>>>>> Stephen
>>>>>> doesn't either. But maybe Heather does and wants to exert effort on
>>>>>> them.
>>>>>> Maybe she wants to verify them and post official ones of which she
>>>>>> approves.
>>>>>> Peachy. I don't care to know.
>>>>>>
>>>>>> - I like suggestions for changes to specs. They should be tracked,
>>>>>> posted
>>>>>> publicly, and discussed by those who are interested in that spec.
>>>>>> But they
>>>>>> shouldn't have to be marked as "Formally Approved By The Powers That
>>>>>> Be",
>>>>>> and I shouldn't need to spend my time looking at them unless I'm
>>>>>> interested
>>>>>> too.
>>>>>>
>>>>>> - If there's an overt error in a spec that causes implementation
>>>>>> and/or
>>>>>> interoperability problems, *and it's non-obvious*, those should be
>>>>>> called
>>>>>> out with red flags and fanfare in some well-known place that people
>>>>>> know to
>>>>>> go to for such important information, and someone in a position of
>>>>>> responsibility should mark it as such.
>>>>>>
>>>>>> My sense is that part of the problem is that we've got once system
>>>>>> to deal
>>>>>> with the above, so we all end up spending time and effort on all
>>>>>> three of
>>>>>> the above. That's not good. The IESG (or chairs or whoever)
>>>>>> *should* be
>>>>>> stuck with spending time or effort on the third, but not on the
>>>>>> first two.
>>>>>> Maybe the RFC Editor should spend time or effort on the first, but
>>>>>> the
>>>>>> getting the IESG involved is highly silly. If we dealt with these
>>>>>> things
>>>>>> separately, I think overall happiness would be increased
>>>>>> substantially.
>>>>>>
>>>>>> pr
>>>>>>
>>>>>> -- 
>>>>>> Pete Resnick<http://www.qualcomm.com/~presnick/>
>>>>>> Qualcomm Technologies, Inc. - [phone]
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Errata-design mailing list
>>>>>> [e-mail]
>>>>>> https://www.rfc-editor.org/mailman/listinfo/errata-design
>>>>>>
>>>>>>            
>>>      
>> _______________________________________________
>> Errata-design mailing list
>> [e-mail]
>> https://www.rfc-editor.org/mailman/listinfo/errata-design
>>    
>