[Members] XSF @ 10

Kevin Smith kevin at kismith.co.uk
Wed Jul 13 09:12:47 UTC 2011

I'm aware that this post seems to be largely against reform - I am, as
I've noted in recent meetings (I think both Council and heckling Board
meetings), in favour of reform for solving our operational problems -
I think we should discuss how we go about it, which is where this is

On Tue, Jul 12, 2011 at 10:03 PM, Peter Saint-Andre <stpeter at stpeter.im> 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).

I agree with some of this.

> 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.

Is this true? I know that some older XMPP projects are no longer
active, but my impression is that the number of active projects is
still growing over time.

> 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.

I think it would be worth working out (or listing, if we already know
them) the problems with bureaucracy in the XSF (note that I don't
claim they're not there), and this seems to be pretty vital to
addressing them.

> The XSF has one core purpose: to public high-quality protocol specs and
> related materials (schemas, registries, etc.). Our websites, servers,
> validation software (I wish!), and other tools exist to support that
> basic mission. If we have organizational cruft, then let's clean it out
> as much as possible. (Some changes might not be possible given the XSF's
> legal structure.)

I'm in favour of this.

> The basic idea floating in my head is to make the XSF into something
> like an "open-spec project". A meritocracy, not a bureaucracy. Just as
> with open-source projects, the XSF as an open-spec project would have
> two basic levels of involvement: contributors and committers.

This seems to be an approach of realising something is wrong with the
existing system (I agree), and trying something that seems to be
different in the hope that it's better, rather than deciding what
needs to change, what is good (yes, there are still good things about
the XSF!) and making sure we address one set without breaking the

> A contributor would be anyone who writes specs, maintains the
> registries, reports bugs, submits patches, helps out with the
> infrastructure, edits the website or the wiki, runs the Summits, codes
> our tools, mentors GSoC students, assists new developers, helps people
> deploy XMPP, etc.

Right, in an ideal world this would be akin to a current member,
although I realise not all members currently contribute (true, I
think, of the membership at large, and also within each team/body).

> A committer would be anyone with full or partial commit access to our
> core output: specs, schemas, registries, etc.

I think we, as I understand from Dave's suggestion later, could do
with more fine-grained and more inclusive access to the specs - such
that authors can edit their own specs at will without needing to pass
through the XEP Editor.

> Yes, we also might need project leads and even overall "leadership" of
> some kind, but I'd really like us to evolve beyond "members" and
> "leaders" toward "contributors" and "committers".

I think there's less difference between these things than one might think.

> This would require some changes in our bylaws, but those changes are
> easy compared to the changes needed in our thinking and attitudes.
> Members would need to think and act as contributors -- not as people who
> just like XMPP and vote four times a year.

There is certainly an issue here, and it seems worthwhile to solve.

> Leaders (XMPP Council members, XSF Board members, etc.) would need to
> think and act as committers, as stewards of the technology, and as
> mentors of our contributors -- not as anointed experts who have a
> permanent place at the top and can say no to new ideas. (And yes, I
> include myself in that criticism!)

There is also an issue here, and it seems worthwhile to solve,
although I suspect it's a subset of what's expressed here.
In theory positions on Board and Council are not blessed for life, as
the membership gets to rechoose every year. In practice, the dynamic
of membership voting means that the incumbents almost always return if
they stand. It's not clear to me where the root of this problem is (or
if it's just that the incumbents have always been the best people for
the job - although I believe this to be false) - but it seems at first
glance that a system like an open source project where (typically)
places are granted from on high rather than voted from the masses
would be less democratic and less open than what we currently have.

I'd like to turn the discussion towards working out the operational
problems our current system is causing us as a first step.

"Council seats are effectively for life" isn't really an operational
problem (The XSF's raison d'être isn't "having a varied Council").
"Council stagnation means that the old farts never let new ideas
through, and good XEPs are blocked from ever being published" would be
(is?) an operational concern - The XSF exists, in large part, for
publishing high-quality XEPs.


More information about the Members mailing list