[standards-jig] JEPs and Jabber Adoption
thoutbeckers at splendo.com
Sat Jun 28 17:48:52 UTC 2003
Thomas Muldowney <temas at box5.net> wrote on 28-6-2003 19:37:03:
>I have felt this is a problem for a long time. Many times now I've
>advocated a 75% vote for something to pass, not 100%. Is it time to
>look at this again? Although, so far, I don't think this has effected
>any of the votes.
That would be a "fix" in some situations.
>> I honestly doubt we would have had much problems with filetransfer
>> if we went ahead with the "old" JEPs. They surthenly would have
>> matured by now, wich is not at all the case for the "new" JEPs we
>> have now that you want to move forward. I'm not saying the new JEPs
>> won't give us something that's slighty better than the old ones, but
>> we would have had filetransfer by now.
>I don't want to dwell on this, because what's done is done, but nearly
>50% of the vocal people did not want to use the previously mentioned
I think there's a differency. Maybe 50% didn't like the idea at first
sight. But I remember having to write a number of posts to convince
people there's a need for IBB at all!
>That would have made for a nicely split community, and to
>me that's exactly what we need to avoid.
I still think, once there would be some implementation of those JEPs
after they would have been advanced to DRAFT (by the other 50% ;)
people would have come around (including you?). However, if a
substantial number of those 50% (including you?) would have still not
liked the idea at all, they could have written a competing spec, and we
would have seen wich one is best (as well as discuss this on the list).
Can you imagine linux kernel hackers debating for years about what new
scheduler to use, and have nothing beyond very experimental work
happing cause some fictional "linux council" would refuse to advance
one beyond experimental?
Ofcourse not.. we have a whole bunch of schedulers outthere now.
They're not "experimental" either, they are real implementations,
outthere, and being used. Wich one will make it into the official
kernel branch? And maybe some that won't will still be maintained cause
they perform better under special circumstances. You could compare that
to advancing to "ACTIVE" or "FINAL".
You'll *never* get those guys to agree on what's the best scheduler by
just talking about it on a mailinglist. However, they can still all be
happy with the outcome, even if it isn't their own plan, and their own
schedular that "wins".
>> Ofcourse, this way of working has it's advantages. We end up with
>> something for wich, after a long long while there is probably more
>> concensus on than any other protocol that would have come out in a
>> different process. We can also be sure that from a technical point
>> of view it's ok. But do these advantages weigh up disavantages: the
>> immensly slower pace of innovation, the immensly longer time-
>> consuming discussions.
>I like the process, except for one key part: The utter lack of
>community support! I'm completely serious about this. How many people
>say absolutely nothing when a new JEP comes out? How many people reply
>to a new revision? How many people even answer simple questions by the
>authors? Damn near no one! Look at every major discussion on s-jig.
>It hasn't happened until a JEP was right about to go last call. People
>need to be more active throughout the development of JEPs, and the
>authors need to be more out in the open with their development. I
>think there are way more than enough people around for us to quickly
>get something together and through the door if everyone is actively
How many people are tired of doing exactly what you want because of the
never-ending discussions about rather trivial things that keep a JEP
from advancing further? This happens because currently council (and
more or less the community) has to agree on every item before you can
progress. It seems that when you take your idea ("innovation") to the
community world+dog has to have their say about it, and you better
listen to each and every one of them of your JEP will go nowhere.
Why not rather if someone has a nice idea, give them some feedback from
the community and the council, and then advance their proposal to DRAFT.
Once it's implemented by whoever likes it, come back again and see if
you like it or not. Does it get the job done in a good way? Great, we
now have filetransfer. Are there still some flaws? As a community we
can then work on fixing them together. Is the protocol critically
flawed? Too bad, better luck next time. Since there's room for others
to do the same as this guy/girl concurrently (though not necisarly at
the same stage, as the proces now seems to result in), another, maybe
better protocol might be already be in the pipeline.
>I think letting through multiple versions of similar protocols is an
>extreme waste of time.
Say, wich filesystem do you use? Ext3? JFS? ReiserFS? Good old Ext2? Hm.
. what do you like better, GTK+ or QT? GNOME or KDE? What do you use to
show your processes, ps or top? Let's discuss that for a few years,
have a council decides what's best, and then implement it. As far as I
can see, that's not really working.
>I think the council needs to be more active in
>getting all the parties interested in a topic together (that's what I
>tried to do with FT) and working hard to find a solutino that is
Currently, I come up with an idea to do something. I take it to the
community. Some people point out little flaws I can fix. Others though,
disagree with the idea I have (not per se with what I'm trying to do!).
The council takes sides, and we come to a standstill. Enter:
competetive JEP to do the same thing. I remember things said (not to
me) that come down to "change your idea to my idea, or I'll make my own
JEP!". That wouldn't even be a bad thing. But in the current situation
this means *my* idea isn't allowed to move forward any more. Nothing
left to do but abondon it and let the next guy try..
IMHO, the "experimental" fase of the JEP isn't best place for ideas to
compete with each other (*and* influence each other!), but in the
current process this is exactly where ideas get locked in, until some
magic universal agreement.
>The council can not be a backburner group waiting
>for the vote, it needs to be fully proactive in protocol growth.
>Couple this with my previously mentioned help from everyone on s-jig
>and we can get a system together quickly.
>So to summarise my feelings.... council should be proactive in getting
>the community together behind single subjects and hammering them out as
>quickly as possible. The s-jig members need to be proactive with their
>voices and spelling out their feelings at every step of the way. When
>a new JEP comes out I want to see 5 emails saying, hey I like this, but
>did you think about this point enough? Or, I think you have a
>potential flaw in point XYZ. Plus, we have the protocol gatherings
>for active discussion on topics. It would probably help if we didn't
>have so many controversial topics for the past while, but I think
>that's about done. The blame is on everyone, and the responsibility
>for the future is on everyone, so let's take that and move forward
>rather than dwelling on whether the process works or not, because I
>honestly think it _can_ once these two aspects take shape.
I think a lot of SJIG members do put in a lot of effort. But when your
effort and/or ideas are not able to move forward for no *good* reason,
one get's tired and gives up. I'd even dare to say that, in the current
structure, if everyone puts in some extra effort things will only move
Just think about it, we *do* see that when a JEP comes out little flaws
are pointed out to each other, but once someone stands up and says "you
should change your JEP from your idea to my idea" all that effort gets
wasted, cause there is no room for either to move forward. That's very
demotivating for everyone involved.
Software Engineer @ Splendo
More information about the Standards