[standards-jig] informational vs. standards-track
matt at jivesoftware.com
Wed Jul 30 04:53:31 UTC 2003
>>> Further, I intend to document the internal jabberd2 protocols in exactly
>>> the same way.
>> I think that's great but that it just shouldn't be called JEP's.
> This is clearly flame-bait, but DUDE, is there anything in the JSF you
> _don't_ want to change? ;)
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
2) Have had tons of confusion over what JEP's they should implement in
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
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."
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.
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.
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.
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.
More information about the Standards