[standards-jig] JEPs and Jabber Adoption

Tijl Houtbeckers 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
>generally agreeable.

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 
forward *slower*. 

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. 

Tijl Houtbeckers

Software Engineer @ Splendo
The Netherlands

More information about the Standards mailing list