[Foundation] JIGs and JEEPs

Rahul Dave rahul at reno.cis.upenn.edu
Thu May 24 17:27:38 CDT 2001


I got this from you:
> 
> 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? :).
Hey, Sounds Good!

What should be appropriate for a JEEP? I'd say anything that needs tracking, 
so that the energy spent by the appropriate mailing list in working on that
subject is not dissipated. This could be a proposal to merge the forums and
mailing lists, a new transport, a new app (for example sending SOAP over
jabber using Net::Jabber and SOAP::Lite), a new document. Anything the
sponsor wants to communicate that he or she or they are working on. It serves
as an informal, classified only by JIG activity communication mechanism.

And for general or Biz JIG, the JEEP would serve as an RFC..
> 
> 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.
As I said above, it need not be just this..
It would work for additions to the server, clients anything.
It ought to be left upto the individual JIG's to decide if JEEP's are too
heavyweight for them..this may be true for clients.
For docs, server, protocol, arch, general and even middleware, I think
it will be a good idea though.
> 
> 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.
We ought to have announce capable mailing lists, or retool some of the existing
lists for this purpose.., like server-dev would be for server JIG..
> 
> 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 
Why ought Jabelin to not be part of the server JIG?
> 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 ?)
We could use this list for them..
> 
> 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.
Makes sense..
> 
> 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.

Definitely lets add this
> 
> 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.
What about core server development?
> 
> 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.
Hmm, this sounds like a good idea, and woulld include middleware, transports
too
> 
> 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.
So we are adding docs and components, subsuming infra into general.
I would hope the jabelin(open source jabber server, right?) server team
would use the server JIG.

Personally I'd keep the standards JIG for the simple reason that it would
be the focal point of the CORE (read, not x namespace) standards development.
Components would handle x.
> 
> 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?

3 is a good idea, but there should be one leader with technical chops, and
someone ..Jer.. should be benevolent dictator. Somewhat like linux kernel.
Miller decides what goes into networking, but Linus has overall say. His
decision is final.

How to get these people? Yesterday I thought volunteer +election. I think this
would be ok for the other two, but for the leader, getting the general sig
to approve sounds like a great idea.
Rahul
> 
> 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
> 




More information about the Members mailing list