[Members] XSF @ 10

[Dave Cridland]

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.

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.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade