[Members] XSF @ 10
dave at cridland.net
Tue Jul 12 22:54:06 UTC 2011
On Tue Jul 12 22:03:32 2011, Peter Saint-Andre wrote:
> I see one basic problem in our community: we have too much
> (XSF processes and procedures, voting, teams, boards, councils) and
> little energy (individual contributions, actions, and decisions).
> Some of this is caused by the maturity of XMPP -- it's no longer a
> new technology, we have fewer active code projects, etc. However,
> of it is caused by excessive bureaucracy within the XSF. I can't
> 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 Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Members