[standards-jig] informational vs. standards-track

Robert Norris rob at cataclysm.cx
Wed Jul 30 05:58:53 UTC 2003


> Any joking aside, I think the current JEP process does need some
> change.  I've read many comments recently from people that:
> 
>  1) Are frustrated that there has been so little progress on some
>  important JEP's.

So hassle the authors. Or take it on and finish it yourself.

>  2) Have had tons of confusion over what JEP's they should implement
>  in their clients.

Implement whatever you like or need. Implement whatever everybody else
is implementing.

> Having a bunch of informational JEP's that don't go through a real
> approval/review process doesn't seem like it will help with those
> issues. Let's imagine a hypothetical conversation about an
> informational JEP:
> 
> Tom: "Hey Joe, how about changing XYZ in your informational JEP ABC?
> Without the change the protocol is broken for reason 123."
> 
> Joe: "Neah. I already implemented stuff the way I described it in the
> JEP and an informational JEP is just meant to document something that
> was already done."

If Joe won't take constructive feedback about why his protocol is
broken, then he's an idiot. I doubt this would happen, because most
people take some pride in their work.

And there is _nothing_ to stop Tom forking and making his own changes.
This sort of thing happens all the time, and is rarely a bad thing.

> How can we resolve disputes like that when there is no process in
> place?  To me, that's what the whole standards process is for.

How do you resolve disputes normally? Do you talk to the people involved
and try to find common ground, or do you get a large hammer and beat
them into submission?

If something is broken, you can fix it yourself and tell everyone else
about it so they start doing it your way instead. And if noone seems
interested, then perhaps you're wrong about it being broken. Or perhaps
its not important enough.

> All I'm advocating is for higher quality JEP's and that anything that
> appears to be an official protocol from the JSF is actually that. I
> actually think that more things should be standards-track then are
> now.  So, anything that is an informational JEP now should certainly
> qualify to become standards track if so desired.

Depends on what it means for something to be Standards Track. At the
moment, its fuzzy. Perhaps thats the only issue in this whole debate -
maybe we're just debating semantics.

> If people aren't happy with getting rid of informational JEP's then I
> think there are other alternatives that should work too, such as:
> 
>  1) List standards-track and informational JEP's completely
>  seperately.

Not unreasonable, though there is a drop-down box on the JEP page that
lets you restrict your view to one or the other.

>  2) Include a prominent disclaimer at the top of each informational
>  JEP that it's not standards-track and what that might mean to people
>  looking to adopt it.

What does it mean, exactly?

Rob.

-- 
Robert Norris                                       GPG: 1024D/FC18E6C2
Email+Jabber: rob at cataclysm.cx                Web: http://cataclysm.cx/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20030730/fe11ce1e/attachment.sig>


More information about the Standards mailing list