[Foundation] JIGs and JEEPs
stpeter at jabber.org
Thu May 24 16:22:13 CDT 2001
I like the idea of borrowing ideas from other successful projects, and
Python is certainly one of them. However, Jabber is a little different
from Python (and Apache etc.) because it has two aspects: protocol and
code (and, it could be argued, architecture). So I'm struggling a bit in
trying to map Python's SIGs and PEPs over to Jabber's JIGs and JEEPs
(gotta work on that acronym, though -- maybe it stands for Jabber
Enhancement/Extension Proposal? :).
Python has 13 SIGs (http://www.python.org/sigs/), some of which are
platform-focused (MacOS) or area-specific (Python in education), but
most of which are focused on specific aspects of the language (Image
Processing, Databases, etc.) as well as architectural issues (Import
Architecture Redesign, probably also Internationalization). They also
have a Documentation SIG, which is something I think we need as well.
Note that membership in a Python SIG occurs when you sign up for the
SIG's mailing list. In the Jabber world this would be a good way to
involve what in yesterday's meeting we called "Associate Members".
The PEPs (http://python.sourceforge.net/peps/) are specific "feature
requests" regarding the language. PEPs seem to include a few items
related to "project management" (e.g., "Python 2.1 Release Schedule")
and packaging (e.g., "2.0 Batteries Included"), but are mostly focused
on core language features. It seems to me that the parallel be in the
Jabber world would be additons/enhancements to the protocol.
Jabber currently has 22 mailing lists, many of which are
platform-specific (e.g., mac-dev), language-specific (e.g., python-dev)
or project-specific (e.g., server-dev, wcs-dev). Some are more general
(e.g., the security list), but really only two (jdev and jadmin) get a
significant amount of traffic. Furthermore, the JADMIN list is (mostly)
specific to the server that will soon be known as Jabelin. JDEV also
sees a lot of questions that are specific to the current codebase.
With Jabelin splitting off into its own project, it seems to me that
JIGs will focus on topics that are general -- i.e., not specific to
Jabelin or to any particular platform or language. (However, I still
think there might be value in having forums for the latter, so that all
the Perl fans or Mac-heads can get together and compare notes etc. --
would those not be hosted through the Jabber Foundation?)
That said, the list of JIGs that we came up with in yesterday's meeting
and after seems pretty good to me, with the addition of a docs-jig and
perhaps a little re-jiggering here and there (mainly in my mind to align
with some of the thinking behind the recent Jabber Progress Report, see
http://jabber.org/?oid=1406). Taking the best from all materials I can
find, here is how I understand the JIGs:
1. meta-jig (General Foundation Stuff) -- includes management of and
policies for all other JIGs. (Is this different from the "Executive
Committee" mentioned in the proposed articles of incorporation at
2. infra-jig (Foundation Infrastructure) -- jabber.org website, mailing
lists, development tools, CVS, etc. Could this be rolled into the
meta-jig as a sub-team? That makes sense to me.
3. docs-jig (Documentation) -- kinda speaks for itself. Lots of work to
be done here. :) May develop JEEPs related to documentation standards,
and will definitely work with the other JEEP-creating JIGs.
4. biz-jig (Standards Conformance, Business Relations) -- evaluates
projects and products for conformance/compliance with standards of
"Jabber purity" and such (but it seems to me that those standards
actually are developed by other JIGs). Perhaps markets or evangelizes
Jabber. Also in Dave Rahul's definition handles financial matters, legal
issues, and general management of the foundation. However, I'm wondering
if the management functions are better off handled by the Board of
Directors, that's what we're paying them the big bucks for! :)
5. security-jig (Security) -- develops security standards, completes
security audits, creates JEEPs related to security, authentication,
privacy, and the like.
6. client-jig (Client Development) -- creates standards and guidelines
(including JEEPs) for Jabber client functionality. Delivers those
standards to the biz-jig. Sub-projects here might include text
formatting, file transfer, and web intergration.
7. server-jig (Server Development) -- creates standards and guidelines
for Jabber servers (core XML routing, probably Jabber-as-middleware) in
whatever language. Delivers those standards to the biz-jig. Might work
together with client-jig and component-jig to develop JEEPs related to
"cross-functional" protocol like browsing, presence management, and
8. component-jig (Component Development) -- creates standards and
guidelines (including JEEPs) related to the development of internal and
external server components. Delivers those standards to the biz-jig.
Sub-projects here might include conferencing, database integration,
whiteboarding, and transports.
This is a longer list than some have proposed, and shorter than others.
I think it would be good to be in the 7 +/- 2 range. If we roll
infra-jig into meta-jig, we have 7 JIGs, which I think is a manageable
number. Also note the absence of a standards-jig or protocol-jig -- I
think each appropriate JIG can define protocol extensions, with the
meta-jig coordinating among JIGs if necessary (e.g., client-jig and
server-jig need to work together on protocol item X) and with the
meta-jig presenting JEEPs to the general membership (or whatever) for
As to the organization of JIGs, I would prefer (especially after a chat
with Ryan Eatmon yesterday) to have a small "ruling council" for each
JIG rather than one head person. Ryan suggested having 5 people on each
council, but I think that 3 people on the council might be better
(mainly so I can call it a triumvirate, but also because I think it
might be hard to find 5 people for some of these JIGs -- hopefully I'm
wrong about that :). However, 5 people would give us more input and
different perspectives, which would probably be valuable. Each council
member would serve a defined period of time (6 months?) and then would
need to be re-appointed / re-elected. I'm not sure how council members
would gain their positions, perhaps they volunteer and are approved by
Those are my thoughts so far, hopefully you've found them useful.
stpeter at jabber.org
More information about the Members