[Foundation] JIGs and JEEPs

[Peter Saint-Andre]

Some ramblings....

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 
http://foundation.jabber.org/bylaws-draft.html ?)

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

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

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 
the meta-jig?

Those are my thoughts so far, hopefully you've found them useful.

Peter

-- 
Peter Saint-Andre
stpeter at jabber.org