XSF Board of Directors
La XSF (XMPP Standards Foundation) est l’entité qui gère les spécifications du protocole XMPP : les spécifications seulement, pas les logiciels.
Schématiquement, voici les différents groupes que l’on retrouve dans la fondation :
- Il y a des membres, acceptés par cooptation, en reconnaissance d’un travail effectué dans le monde XMPP.
- Le Council est le conseil technique, celui qui décide de prendre en charge les propositions de XEP (XMPP Extension Protocol), qui les maintient et fini au bout d’un certain temps par en proposer à l’IETF.
- La Board of Directors (ou Conseil d’Administration) assure la direction de la fondation, au niveau légal et business, et en donne les orientations futures.
Certains d’entre vous l’ont peut-être déjà vu passer, je me présente au conseil d’administration ou Board of Directors.
Cette candidature est tout à fait sérieuse, même si je ne me mets pas la pression à ce sujet. Je vous encourage à la lire, bien qu’elle ai été rédigée rapidement.
Je peux apporter à ce CA un peu plus de dynamique, de communication, et d’écoute de la communauté.
J’écris cet article ce matin, pour lancer un appel à la communauté francophone XMPP : je fais appel à toi, cher lecteur, pour te demander ce que la XSF pourrait améliorer. Le but n’est uniquement de consolider ma candidature, mais surtout d’apporter de la matière à réflexion au CA et aux candidats actuels.
La clôture des candidatures étant fixé à… aujourd’hui (11 septembre), je vous propose de commenter cet article, disons avant 18h (je sais, c’est très court, désolé), et je mettrai à jour ma candidature. Les votes auront lieu du 14 au 30… par les membres.
Merci d’avance, à vos claviers…
Nÿco (nyco) 's status on Friday, 11-Sep-09 09:01:24 UTC - Identi.ca 10:01 on 2009-09-11 Permalien |
[...] XSF Board of Directors « [Nÿco's blog] standards ouverts de la messagerie insta… a few seconds ago from identichat [...]
Gam 10:40 on 2009-09-11 Permalien |
Ce qu’il faut améliorer ? il faut de la réactivité ! Je sais bien qu’il faut que les extensions soient parfaites, mais plusieurs années pour finir Jingle (et encore, sans le transfert de fichiers) c’est trop, beaucoup trop.
Pour que Jabber commence a bien prendre il faut que ce protocole en propose encore plus que les autres. Le fait que ce soit libre n’est pour l’utilisateur final que la cerise sur le gateau.
A quand des transferts de fichiers qui fonctionnent vraiment partout (jingle) ? a quand un partage d’écran ou un tableau blanc finalisé ? Autre ?
nyco 11:01 on 2009-09-11 Permalien |
Bien joué, rajouté.
Cela dit, une spec met du temps à se stabiliser : du besoin, en passant par le brouillon spec, puis l’amélioration de celle-ci, le début des implémentations, le feedback de celles-ci, et la stabilisation de la spec… ça prend logiquement beaucoup de temps.
YomeGuy 11:10 on 2009-09-11 Permalien |
Si cela n’existe pas , il pourrait etre interessant de reflechir à un projet type Spamhaus Block List (black list de serveurs pour l’e-mail), pour organiser la lutte contre les sources de spam Jabber
http://www.spamhaus.org/organization/index.lasso
nyco 11:14 on 2009-09-11 Permalien |
Très juste.
Comme je t’ai pointé, il y a la XAAI : XMPP anti-abuse initiative
https://support.process-one.net/doc/display/XAAI/Home
Jeremy 11:45 on 2009-09-11 Permalien |
Que cela prenne du temps, oui, mais plusieurs années ? Je rejoins Gam, il faut que les specs sortent plus vite, quelques mois, un an tout au plus. Après, le temps que les développeurs l’implémente, ca devient obsolète.
Dave Cridland 13:09 on 2009-09-11 Permalien |
With a bit of help from Google, I can understand this, but I’m afraid my French simply isn’t good enough to make the points I need to. Feel free to translate me – I’ve seen what Google Translate did to Nyco’s post, though. :-)
Developing specifications faster is a good goal for the XSF, but it’s not all down to the Board, or the Council.
I’ve served on the Council now for a while, including the last session where we did approve Jingle, and many of the related specifications, to Draft status. We didn’t, however, “make” the specifications Draft, we simply made the call on when they were ready. Making that call if the specifications are not ready would be – I hope you agree – a disaster.
Actually making these specifications ready is something that involves both the XSF membership as a whole, and also the wider XMPP community. It’s very hard to rush this, but we could probably make it quicker. The problem is that the only way of making it quicker is to get more people working on it, and making an implementation which tracks a specification under development is much harder than waiting for the specification to be proven by others first and stabilised.
We have, however, taken steps recently to ensure that specifications remain stable throughout their lifetime – in particular, we changed namespacing rules to allow continued interoperability between the same experimental versions of the protocol. Previously, one of the major problems was that a XEP kept the name namespaces throughout it’s time as Experimental, making them very difficult to deploy in any form. This, then, helps mitigate the risk of implementing a XEP still in Experimental state, which in turn hopefully reduces the cost of tracking an experimental XEP. Finding other ways the Council, as the technical leadership of the XSF, can help is a good goal.
The other thing we can do is to hold more interop events, in person. But these cost money, both to the XSF and the participants. The Jingle Thingle, back in February, was a huge step forward in moving Jingle to Draft, and it’s fair to say we need to consider how to make more of these happen, and that’s certainly something the Board can help with.
Gam 13:35 on 2009-09-11 Permalien |
Excusez-moi de répondre en français. Je lis plutot bien l’anglais, mais mes qualités rédactionnelles dans cette langue sont malheureusement assez limitées.
Loin de moi l’idée d’émettre un quelconque reproche envers tout le travail déjà effectué par la XSF. Celà serait particulièrement malvenu de ma part devant tout le travail effectué et surtout de la part de quelqu’un qui n’y a pas participé (Ah si je savais vraiment programmer ….).
Je me permets seulement, suite à la demande de Nyco et en temps qu’utilisateur, de vous dire que la réactivité doit faire partie des toutes premières priorités si on veut que Jabber ne soit pas vite complètement largué en terme de fonctionnalités (d’un point de vue utilisateur final).
Pour que Jabber perce, il faudra qu’il fasse rapidement au moins ce que font les autres (surtout AIM et MSN), pas en sortant une nouvelle fonctionnalité tous les 2/3/4 ans.
nyco 13:43 on 2009-09-11 Permalien |
It’s hard to explain why it’s slow to publish a XEP in draft, but it’s also true we need to move faster.
Gather more people for review and implementaton leads to more management needs (which we might be able to achieve), and of course, as a side-effect more noise…
What would you propose as solutions to address these issues?
Gam 13:49 on 2009-09-11 Permalien |
Sorry but I criticize without solutions, like all good french people :-) But i’m thinking about it …
Gam 13:44 on 2009-09-11 Permalien |
Attention, quand je parle d’une nouvelle fonctionnalité, je parle d’une fonctionnalité majeure et d’un point de vue utilisateur final (video/transfert de fichiers/white board etc).
nyco 13:45 on 2009-09-11 Permalien |
On avait compris ;-)
Dave Cridland 14:05 on 2009-09-11 Permalien |
The problem is that we’ve done this before, too quickly, and the result is a protocol that is either broken – and yet too firmly entrenched to replace easily – or never deployed at all – and yet essentially acts as a block to new replacements.
Consider file-transfer, which you mentioned before. I agree entirely – file transfer’s current state is often virtually unusable, and it’d be great to move to Jingle-FT. But the existing, SI-based file-transfer just about works in just about enough cases to mean client developers have more important things to work on.
And an example from the VOIP case is TINS, although I think there were other attempts, too.
So we have to be both cautious – and careful – and yet fast, too. We don’t have the luxury of controlling the servers or the clients, either, so merely having Jingle-FT specified has not, yet, resulted in people using it.
It’s pretty easy to get these things working if you’ve only the one implementation to worry about, too – there’s XMPP clients doing all the things you mention in their own, special, way. If MSN or AOL wanted to do this, they have only one client, which they write, so it’s pretty simple. Luckily we don’t have only one server, or only one client – we’ve got a vibrant market with many actively developed XMPP products, open-source and not – we need to find some way of taking advantage of this to push adoption and development of the XEPs.
Cédric 21:07 on 2009-09-11 Permalien |
Salut,
Je me permet, le tout étant, si les XEPS sont abouties, c’est au minimum pour reprendre les fonctionnalités qui existent déjà sur des clients propriétaires, comme l’audio et la video par exemple
Par ailleurs, le problème est qu’on voit pas forcément les vraies avantages qu’elles apporteraient en terme de fonctionnalités par rapport à la conccurence, en terme d’ergonomie, ou des formats, je pense que c’est sûrement le cas, mais j’avoue que c’est pas encore vraiment très évident à voir.
Et enfin au vu des contributeurs qui participent à l’élobarations des XEPS, depuis que je suis sur jabber, je ne vois pas leur nombre augmenter, peut être que ca permetterait de faire avancer les choses déjà à ce niveau.