[Members] XSF @ 10

jehan at zemarmot.net jehan at zemarmot.net
Wed Jul 13 04:39:58 UTC 2011


On Tue, 12 Jul 2011 23:54:06 +0100, Dave Cridland <dave at cridland.net>
> On Tue Jul 12 22:03:32 2011, Peter Saint-Andre wrote:
>> I see one basic problem in our community: we have too much  > organization
>> (XSF processes and procedures, voting, teams, boards, councils) and  > too
>> little energy (individual contributions, actions, and decisions).
>> > Some of this is caused by the maturity of XMPP -- it's no longer a  > hot
>> new technology, we have fewer active code projects, etc. However,  > some
>> of it is caused by excessive bureaucracy within the XSF. I can't  > cause
>> new projects to emerge, but I can try to fix the XSF to some extent.
> Funnily enough, I've been thinking about this as well, although I 
> think from a different angle.
> I'm not sure - well, no, I *am* very sure that I'm against - throwing
> out everything about the XSF and starting over.
> But I think it probably is worthwhile examining what process we have,
> and ensuring that it's serving the goals it should. I just think that
> we should use what we have as a starting point.
> What I don't think we should be doing is looking at open-source 
> projects and assuming that if we squint, we can look like one. An 
> open-source project produces code, and I think the requirements of an 
> SDO are sufficiently different that the procedures need to also 
> differ. Moreover, I don't think the XSF is so broken that everything 
> we do must entirely change to improve, and I don't think radical 
> change automatically brings improvement.
> An example - it seems to be much more difficult than it should be to 
> get Experimental specs published. I think it'd be worth the members 
> deciding on the ground that a proposal should be rejected by the 
> Council. One case might be that a deployed protocol covers this 
> already. At the moment, I think we have a quality creep on our 
> publication bar, which has the effect of stifling new XEPs. Our 
> Experimental XEPs don't have the same blessed status as an RFC; we 
> should nip this one in the bud now to avoid it.
> Another example, in the same vein - it feels, to me, that as long as 
> the format is publishable, it should be possible to submit a 
> proto-XEP entirely automatically. (The IETF does this with its 
> Internet-Drafts). Editing them if approved should also be trivial - 
> we have git, we have the concept of XEP Authors who'd require 
> sign-off. If it then validates as a XEP, new version is published.
> What you'd see would then be - hopefully - a mass of low-quality XEPs
> published, and their supporters would then be keen to elevate them so
> they'd gain visibility - and it's be fairly trivial to do so.

I don't think most of the problem is about XEP and RFC process. It is
also (mainly?) about XSF organization. Specification procedures can
obviously be improved, but that's not where I see the bigger problem.

Basically here is my vision of membership as a "simple" XSF member: we
are just an excuse to have 4 votes for new members a year.
Outside the XSF, I am quite regularly advocating the XSF and XMPP, in
particular in the French community. I organized a conference event for
the 10 years of XMPP, I am regularly contributing articles about XMPP
advances for French-speaking Free Software community (Ludovic Bocquet
wrote on the members list about this a few days ago) and overall I am
trying to get XMPP contributors (for instance many developers of XMPP
softwares could participate more, if at all) into membership. But
sometimes I am wondering if I am not lying to them.

Since the years I am member, I proposed quite a few things to improve
the XSF, they are most of the time not even discussed. New things are
usually not accepted. Also sometimes, and that is really the worst, I am
just told "there is a procedure, you did not follow it". So yes I am not
perfectly aware of the whole complicated procedures. I try to be but am
not. But why did the form totally eclipse the contents? I made a
procedure mistake, hence I cannot propose ideas, at least for
My feeling in the XSF in such a case is that the "powerful" crush the
"simple one" (hopefully that's not always true). Also sometimes some
same powerful (whether because they are of the board, the council, other
important position or simply because they have been here for so many
years that they maybe consider us as "noobs") don't even participate
much, miss their meetings, do not vote themselves, do not answer the
list, etc. But they still block us from participating. So in the end,
the XSF does not move.

So I want to be clear. I am not saying everyone should be perfect. I
perfectly understand that XSF is not *everything*. Myself I don't have
that a lot of time to give to the XSF. And I understand that, even a
board member for instance could be too busy or care about other stuffs,
more important, at some point. This is not my point. What I am saying is
that simple members should be listened too, given some credits and some
capacity to do the things they propose, especially when they try to
help. Everyone cannot be an extra contributor like Peter, but the time
we are able to and propose to contribute, this is too bad it is wasted
on us.

So I totally back Peter up on this. We should have a XSF more flexible,
more open and less procedural, a XSF where the contribution matters
(instead of procedures).
And in particular we should allow people to contribute, whatever their
"rank" (it is even sad I have to precise this point in a standards
organization). Because if each of us cannot necessary give a lot, most
of us can and want to give at least a little, and that all together will
be a lot.

> So in summary, at the moment, I think our process (and system) is 
> more awkward, and less automated, than it could be. But I don't think 
> it's fundamentally broken, I just think it needs a refresh. If only 
> we knew people who could offer suggestions about minimizing 
> round-trips, and some folk who could write code?
> Dave.

More information about the Members mailing list