[standards-jig] Re: [Foundation] streamlining the JIGs
iainshigeoka at yahoo.com
Mon Feb 25 20:16:50 UTC 2002
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  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.
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
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
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.
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
More information about the Standards