[Foundation] JIGs and JEEPs

[Julian Missig]

Peter,
I've liked various aspects of different proposals and was hoping to see
them combined... I think you've done well. I *really* like things as you
have them layed out below.

Starting off with 3 council members per JIG sounds good. Initial
positions should probably be on a volunteer basis. There might need to
be a set limit on how many JIG councils a person can be in... I'm not
sure.

Julian

On 24 May 2001 15:22:13 -0600, Peter Saint-Andre wrote:
> 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
> 
> _______________________________________________
> Members mailing list
> Members at jabber.org
> http://mailman.jabber.org/listinfo/members

-- 
email: julian at jabber.org
jabber:julian at jabber.org