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

[Pete Resnick <[e-mail]>]

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.

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
>>>        

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - [phone]