[Foundation] JIGs and JEEPs
Julian Missig
julian at jabber.org
Thu May 24 16:52:14 CDT 2001
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
More information about the Members
mailing list