[Web-SIG] Specification process

[Luke Arno]

On 11/1/06, Ian Bicking <ianb at colorstudy.com> wrote:
> 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.
I agree that some repository of documents as
to what conventions exist to enhance interop
between wsgi components is highly valuable.
I would rather see those documents present
real information upon which developers can
decide what to do rationally than an appeal to
authority in order to influence conformity on a
sociological basis. Hence my "bah" :)

A document should describe the convention
and its status in plain language and factual
terms. In this case, I think we should just state
that there is a general consensus and which
implementations do and will support that.
Validators are nice too.

None of that requires formalization thus far.

Some statement on wsgi.org as to our desire
to create interoperable components and our
general commitment to not break our APIs
without good reason might be good. I hope that
goes without saying and if not I tend to think
that actions (should) speak louder than words.

Do we want to draw up some kind of WSGI
community constitution while we are at it? ;) ;)

IMHO, YMMV, yada yada yada.

Cheers,
- Luke