[Web-SIG] Specification process

[Ian Bicking]

Luke Arno wrote:
> On 11/1/06, Ian Bicking <ianb at colorstudy.com> wrote:
>>
>> So, maybe two namespace options:
>>
>> wsgiorg.*
>> websig.*
>>
>> I personally prefer wsgiorg, since we can do this on wsgi.org, and I
>> like what the name implies.
> 
> +1 for wsgiorg as a neutral namespace for building
> compatibility. -1 for process until we have problems
> that process might resolve.
> 
> Premature bureaucratization is a sin worse than
> premature optimization. For my part, it is enough to
> say "hey everybody, we have a few tools that do the
> same thing in different ways (all the various
> dispatchers for instance); do we want to put things
> in a common place in a common way so that these
> tools are interchangeable?" That is all we have really
> done hear and I think it has worked out fine.

I'm not trying to add bureaucracy.  Mostly I'm trying to create 
something where we can tell people where to take ideas for specs, and 
when someone does that they can tell when they are "done".  How formal 
we have to be, I don't know -- I think we can start pretty simple with 
some rules of thumb.  I just want to avoid an ambiguous process where 
the only way to finish is to self-declare yourself done.

Of note is the fact that PEP 333 is still of status "Draft" -- I'd 
rather avoid that limbo.  (Though I think in this case Phillip just can 
self-declare it whatever status seems right?  In which case I'd suggest 
something more assertive than "Draft")

> Creating process is already creating overhead when
> there is no trouble that we need the process to
> address. What additional value comes from lending
> "authority" to this convention (url vars)? Bah! ;)

The "authority" is that:

1) the spec won't change without good reason, so you can start 
implementing against it (once it is "approved")
2) it's useful in multiple contexts
3) having implemented either side, you can expect that maybe *someone* 
will care (either producing or consuming what you are looking for)
4) some eyes have been on it, and it's passed the sanity check (and 
hopefully better than just a sanity check)
5) someone won't implement something they think is the same, but isn't, 
because the spec documents the requirements sufficiently

Going through the process is a marker for all these items.  And really 
that's the only important part, if someone is able to claim all these 
things then maybe that's the only process that is important.

-- 
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org