[standards-jig] Re: [Foundation] streamlining the JIGs

dave at dave.tj dave at dave.tj
Mon Feb 25 21:16:19 UTC 2002

That's way too much formalization at this point, if you ask me.  Save the
email, though, since it'll be quite useful once Jabber really gets off
the ground.  It's just that the current situation (minus most of the JIGs,
which apparently aren't doing much) seems to be working well, while our
attempt at organization (the JIGs) doesn't.  Time constraints are also
a major problem still, so having the ability to pester team leaders
may encourage team leaders to pester their team members, which in turn
encourages them to rush - and anybody who's seen the ANSI C++ standard
knows what happens when people get antsy about finishing up quickly.
If the first JEPs (which will become more-or-less de facto standards by
the time Jabber gets off the ground) are flawed because they were rushed,
we'll have many fundamental problems that'll come back and bite us later,
and there won't be a thing we'll be able to do about them, since the JEPs
will be quite entrenched by the time we notice the problems.  Having 100%
ad-hoc group formation/destruction means the individual team members have
the ability to decide for themselves whether they believe their groups
to be dead, and to vote with their feet (i.e., leave the group mailing
list, or at least quit posting to it).  Having less organization also
makes it a lot easier for a team to disband because of a realization
that no useful JEP is likely to result, rather than being pressured to
produce or disband.

...just my pair of pennies,
Dave Cohen <dave at dave.tj>

Iain Shigeoka wrote:
> On 2/24/02 10:18 PM, "Michael Bauer" <bauer at michaelbauer.com> wrote:
> > 
> > I would take it all the way and reduce it to just one JIG.  Everyone
> > involved with standards has to be aware of the details of security.  I
> > suspect the reverse to be true too.
> I agree.  We can form a security tiger team (see below) when the effort
> starts to close in on a JEP...  I really think we need two lists and one
> JIG.  Standards-discuss, standards-announce, and the Standards JIG.
> Standards-discuss being what is now standards-jig, and the announce list is
> read-only, low-traffic, for JEP announcements that Peter is doing and other
> significant Jabber announcements.
> On 2/25/02 1:18 AM, "Ashvil" <ashvil at i3connect.net> wrote:
> > I agree with your analysis and your proposed solution.
> > 
> > It bugs me that information on Jabber is scattered to different mailing
> > lists and different websites. Reducing the mailing lists and consolidating
> > the information is a step in the right direction. Reducing the formality of
> > JEP process should also help.
> I also agree.  Particularly with the need to consolidate information and
> provide clearer organization of what we already have.  We may be placing too
> high a hope on JabberStudio to take care of these problems...a lot may just
> end up being a bunch of grunt work...  ;)
> As far as the JEP.  I'd like to reword or take a slightly different approach
> to the proposed solution (yeah, I'm always being difficult).  I'm providing
> my own list with embedded explanations.
> 1.  Immediately disband all but the Standards JIG.
> Essentially this follows the first comment of this email from Michael.  We
> should have 2 lists and one JIG.  Security is on-and-off primarily I suspect
> because of time demands on the interested parties and the current state of
> uncertainty concerning the current standards.  The other solution items
> suggest ways to allow a security JIG to be handled when it goes "on" again.
> I know in my own case, I've been personally questioning whether it is worth
> worrying about layering a new security system onto the existing Jabber
> standards if we will be working on a Jabber Next Generation (JNG) spec soon.
> Many of the security changes may require pervasive changes to Jabber and
> these may be best put off until we look at revamping Jabber anyhow...  I'm
> not sure how many other efforts are similarly waiting for the JNG thing to
> start... We had a long discussion of this during the framing JEP debate.
> In the JEP it was also suggested to:
> 2.  Rely on individuals and small, ad-hoc groups to create JEPs.
> 3.  Let the Standards JIG (and in some situations the Security JIG) continue
> providing a forum for discussion of experimental JEPs before they are
> submitted to the Jabber Council.
> 4.  If discussion of a certain topic becomes overwhelming within the
> Standards JIG, send interested parties off to an ad-hoc mailing list [5] for
> a short time. Such a mailing list would be established without any need for
> intervention or approval by the Jabber Council. Once some measure of
> consensus is reached or a stable experimental JEP is produced, the topic
> would be returned to the Standards JIG.
> I like this but I think it may be best to encourage anarchy within a
> structured process.  IMHO, the key is to create accountability and deadline
> pressure.  I believe this can be done simply and without much overhead:
> 2.  Standards JIG is the forum of discussions of all experimental JEPs.  It
> will provide two mailing lists for carrying out these discussions (announce
> and discuss).  All JEPs will be discussed on standards JIG before submission
> to the council. After acceptance, the JEP will be ushered through the JEP
> approval process using the standards JIG for discussions and debates.
> 3.  On a vote in Standards JIG (standards-discuss) of no less than 3 days
> and no more than 7 days, a "tiger team" may be formed.  Votes are Apache
> style (+1,0,-1): you must have +1 or 0 from all voters who decide to vote.
> Any -1 vote will prevent the formation of the tiger team.  Voters must be
> standards-discuss subscribers and members of the Jabber Software Foundation.
> -1 votes will only be accepted if a reason is provided along with the vote.
> Tiger team creation votes are started by the proposed tiger team leader by
> posting a tiger team proposal to the discuss list which include the team
> name, its leader(s), goals (JEPs to create or issues to investigate), and
> schedule for accomplishing the goals.  Tiger teams may be disbanded by a
> vote of no confidence following the same voting procedure as tiger team
> formation.  A vote of no confidence may be called by any JSF member.
> Tiger team
> Only tiger teams may submit JEPs for approval by the council.
> Each tiger team has a focused objective.  To create one or more JEPs and
> have them accepted by the council within a scheduled amount of time
> (typically less than 6 months).  Alternatively, tiger teams may be formed to
> decide whether a JEP should be created at all.
> Each tiger team can be composed on any ad-hoc number of members.  However,
> each tiger team will have a recognized leader (or co-leaders).  The team
> leader is the definitive point of contact for the group.  In addition, they
> are responsible for keep the tiger team focused on the team's mission (e.g.
> creating a JEP) or declaring the team a failure and disbanding the team.
> Tiger teams will have an associated name (e.g. security tiger team).  All
> team discussions on standards-discuss will prepend the tiger team name to
> the subject line to allow people to filter out team discussion traffic, e.g.
> Subject: [standards-discuss][security] this is the subject
> ------------
> Vision
> The envisioned process is as follows:
> 1.  A need is identified and discussed on standards-discuss.
> 2.  A general consensus is built for the need for a JEP and the basic ideas
> that will go into it.
> 3.  A person volunteers (or is volunteered...he he he) to become the tiger
> team leader.
> 4.  The leader writes up (or organizes) the team charter and schedule and
> posts it to discuss for thoughts.
> 5.  When it looks like a practical plan, the leader calls for a vote.
> 6.  Three days pass, votes are accumulated, the team creation vote passes.
> In many ways this is like a preliminary council approval vote on the
> practicality and usefulness of the idea.
> 7.  The JEP is created within the team on the standards-discuss list.
> Non-team members are encouraged to participate in discussion.  The process
> is very ad-hoc and informal.  However, the key is that the team leader is
> now accountable for moving the process forward and ushering the JEP towards
> council-approval ready status.  JSF members can encourage/bug the leader
> when things slow down.
> 8.  The JEP is declared done by the leader and submitted to the council for
> approval.  Or the JEP is not getting done and the leader disbands the group.
> Or the tiger team goes dormant and a JSF member calls for a vote of no
> confidence to disband the group.
> -iain
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig

More information about the Standards mailing list