 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
Spec Lead Guide Where the Rubber Meets the Road: JSR 53 Case Study Eduardo Pelegri-Llopart and Danny Coward divided work on JSR 53 to produce two closely related specifications on JavaServer Pages (JSP) 1.2 and Java Servlet 2.3 technology. To keep their large group of over 30 global corporate and individual participants on track, the spec leads relied on tools and processes that extended beyond the basic infrastructure provided by the Java Community ProcessSM (JCP) Program. No doubt about it: running an expert group in order to produce a
useful Java specification according to the rules and expectations set
forth by the JCP is a challenging,
time-consuming, creative endeavor. Resulting specifications typically
must satisfy demanding commercial interests as well as the open
source requirements of independent consultants and book authors.
The JCP's helpful infrastructure can carry an expert group quite far
down the road to address these needs. But what happens when an expert
group inevitably runs beyond well-marked territory? That is precisely
where the rubber meets the road.
Two Heads Better Than One
Some expert groups such as those for the Enterprise JavaBeansTM
specification and for the JavaTM 2 Platform, Enterprise Edition
(J2EETM) platform specification have performed
more efficiently when two senior people partnered to run them. With
such co-ownership, each leader's particular skills, talents, and
experiences can be put to good use. Group members may find a dual
leadership more responsive and available, as when one is on vacation,
for instance.
Eduardo Pelegri-Llopart and Danny Coward, colleagues at Sun
Microsystems, have formed such a partnership in working with JSR 53.
In an unusual twist -- approved before an Executive Committee existed
to question such unique arrangements -- the JSR 53 expert group is
supposed to produce two specifications primarily because the two are
closely related, with the JavaServer PagesTM (JSP(TM))1.2
specification building on the Java Servlet 2.3
specification. Believing it is "much healthier" to keep
specifications separate and to create them under different spec
leads, Pelegri -- the nominal spec lead who also helped design
the JavaBeansTM 1.0 and led JavaHelpTM 1.0 technology -- took
on the JSP 1.2
specification while Coward addressed the specification on Java
Servlet 2.3 technology.
Pelegri's experiences in leading other expert groups made him
well-suited to lead this one, and Coward's previous work on version
2.2 of Servlet technology gave him the expertise to guide development
of the new version and a marked respect toward the Servlet community.
"I understood my job was not to decide the technology myself but to
listen to the experts, shepherd their best ideas into the next
version of the specification, and make sure they ultimately appeared
in the technology in a way that was agreeable to the whole expert
group," Coward says.
When it comes to running the group, Pelegri realizes two heads are
better than one. "In general, I've found it useful to have Danny
around to help with everything, from technical feedback to having a
second perspective on feedback from the experts. We have been
operating as co-leads from the beginning," says Pelegri. At first,
Pelegri did administrative JCP work for both specifications, but now
they co-operate as two sub-expert groups with overlapping
memberships. "One benefit of our close association is that it is
easier to catch conflicts across the specifications," Pelegri says.
Thirty Experts are Better Than Two
Both Servlet and JSP specifications were served by previous expert
groups. Everyone still available from those expert groups was invited
to rejoin the effort. Others were invited who appeared key to
influencing community adoption, such as book authors, open source
community members, and consultants who promote and implement the
technologies that support them. Every container vendor that supports
JSP or Servlet technology was represented, and tool vendors also
contributed expertise.
The recruiting resulted in a large, knowledgeable expert group of
over 30 participants. "Danny and I accept the tradeoff that a large
expert group helps with adoption, even though it might be a bit
harder to manage," Pelegri notes. The difficulty in managing the
group stems from the experts' uneven participation, which varies
depending on product cycles, the need for their professional
expertise, fluctuations in their personal or corporate interest, and
other things. Some stay involved continuously, but others jump in
only towards the end.
Nevertheless, handling a large number of members is a small price to
pay when the result must be a high quality specification. As Pelegri
puts it, "The strength of the specification follows from the
diversity of the expert group membership."
Email Essential for Large Group
During each JavaOne, JSR 53 experts are encouraged to mix and mingle
over a beer. This yearly informal gathering has been effective in
connecting faces with email addresses. A serious face-to-face meeting
of everyone would be hard to pull off, and with such a large group,
teleconferences are also clearly nonworkable. Instead, the group
communicates by email, generating at times of high activity more than
100 messages a week.
While many participants are used to extended email conversations,
senior employees who rely on conventional meetings typically feel
overwhelmed by the prolific email threads, Pelegri observes. In fact,
it took a while for the group as a whole to hit their communication
stride. To help people with a low tolerance for reading email, the
spec leads encouraged experts to communicate directly with the lead
rather than the entire group. Coward and Pelegri quickly learned that
members in the open source community preferred to air their thoughts
openly. Soon, the spec leads began encouraging the group-wide dialog,
and they assumed the extra task of shaping discussions by emailing
regular summaries to keep every member informed.
The summaries, discretely organized by topic and identified as
'Summary of Topic X' in the email header, helped both chatty and
reticent participants. Another helpful protocol was to label messages
relating only to one spec as 'JSP' or 'Servlet' to aid those
restricting their efforts to just one specification. Some experts
told Coward how much they appreciated how his summaries kept them
informed without having to read everything.
Pelegri was pleased with the group's congenial attitude. "In some
cases opinionated, overall they try to do the right thing for the
specification and the platform. In most cases they are quite willing
to share information with each other," says Pelegri.
Although experts are encouraged to email the group-wide alias for
issues relevant to everyone, they are still allowed to send private
messages to the spec lead alias. That alias goes to four people, Sun
employees all: Pelegri, Coward, and the two leads for the Reference
Implementation (RI) development team -- Craig McClanahan for the
Servlet container and Pierre Delisle for the JSP component.
Email sent to the private alias is not visible to other experts. To
keep participants from assuming that silence on the group alias means
there is no feedback on a topic, and to maintain momentum, the
leaders send summaries of feedback they receive, regardless of the
source. Their summaries may also include decisions and their
justification, status reports, and pointers to new specification
drafts posted to the group's private web site.
All email is saved to record the history of specification
development. Email sent to the -experts groupwide alias is archived
on the group's password-protected public web site while messages sent
to the -leads alias are auto-archived for the benefit of the four
leaders. On their own systems, the leaders each keep track of email
sent directly to them by those circumventing the -leads alias.
Email Poses Unique Challenges
Email may be an essential venue for communication, but it also poses
some unique challenges for a spec lead. The sheer volume of email can
be difficult to handle at times. "With a larger group, there is more
feedback and more opportunity for people to complain," says Pelegri,
but eventually experts come to know each other's personal styles well
enough to maintain perspective and focus.
Occasionally an email will trigger a large shower of messages.
Pelegri explains, "If you go away for some period like a long
weekend, you may come back to a number of mail messages that may have
changed the direction of a discussion that you as spec lead had
carefully worked on." Often when discussion gets hyper-active, people
dive into irrelevant topics in a general free-for-all, Coward says,
and that is when he sends out a summary message to refocus discussion
into what is important.
According to Coward, another email challenge stems from the wide
range in depth of response. Some experts will spend a week mulling
over an idea and discussing it with colleagues before mailing their
conclusions in a detailed, thoughtful reply. Other participants may
simply send a comment of "Yep. It's
fine." or "No, I don't like that-could we change it?" The spec lead
makes sure ideas of all experts get a fair hearing, whether presented
formally or in conversation.
Spec leads of larger groups have greater difficulty tracking people
who do not respond to direct questions. "The experts we have are
normally very close to the battlefield, so when they get busy because
they are close to a deadline, it's hard to get them to respond. What
I have to do is ping them," says Pelegri. What's easy for a group of
six, is logistically impossible for a large group. If Pelegri feels
he must know what members think, he sends a reminder notice. If that
doesn't work, he asks specific individuals who have particular
expertise relevant to the topic he's pursuing.
Occasionally spec leads ask those outside the expert group who have
expertise but who aren't members. "I have to be careful not to expose
private information that is happening in the expert group, but in
some cases there clearly is no privacy issue," says Pelegri, such as
his own ideas that he's already discussed with the group at large. If
in doubt, Pelegri consults the expert group about for advice.
Web Site Infrastructure
While email is the avenue for multi-expert conversation, web sites
are useful places to sort and catalog various kinds of data. The
JCP-supplied page http://jcp.org/jsr/detail/53.jsp allows Pelegri
and Coward to post messages to their team, but there's no way to add
related pages yet.
More interesting is the group's own homegrown web site. "We started
way before there was anything provided by the JCP. Some of the things
[such as providing web sites] that the JCP is doing are because we
did them, and they thought they were good ideas," says Pelegri. Here,
spec leads post new drafts for review, then send go-get-it email.
Members can also access status reports, and all drafts and errata, as
well as lists of members, features to be included, pieces remaining
for each feature area, outstanding issues, and decisions made. On the
lighter side, pictures of social interactions at JavaOne and photos
of individual experts are also posted there.
On Pictures Since they don't have formal face to face meetings, Pelegri
encourages people to send pictures of themselves. "It's hard to get
people to do it, but it's very convenient to be able to put a face
and a name and a style together," he says.
Test Balloons Enable Consensual Decision-Making
Eventually, issues must resolve into decisions, but that doesn't
happen automatically. "If summary emails were the only technique a
spec lead used in an expert group, nothing would ever get decided,"
says Coward. He maintains the answer lies not in adopting formal
voting rules, but in floating test balloons to the group. When
discussion had churned long enough, Coward would summarize
discussions on a topic, identify solutions to a problem, list his own
pros and cons for each known option, and indicate the direction he
considered most useful.
"I kind of test the expert group and see if anyone likes [the
suggested direction] or sees problems with it," Coward explains.
Frequently, the test balloon would mobilize the experts into
consensus. Such methods worked so well for Coward that only once did
the experts' opinions split evenly, requiring him to bang the gavel
and make a final decision for the group. "Making people aware of the
thought processes behind decisions helps build consensus very
effectively," Coward says.
Share Dates to Stay on Schedule
Coward believes the most important tool for meeting deadlines is to
keep the entire group informed when drafts are due. If a draft is
three weeks away, and many issues remain on the table, Coward
suggests sending a message that rallies the troops around the
schedule. "If no one knows you're targeting a date, they won't make
the concerted effort to address the issues. But if people know the
schedule, they'll work together as a community," Coward says.
Experts also need to understand what a draft requires. If a spec lead
says, "We're going to release a public draft in two weeks' time"
experts might panic, knowing some areas of the spec haven't been
completed. Because experts don't know the metric for draft readiness,
they might fail to realize that drafts required by the JCP don't
necessarily have to be entirely complete. Coward recommends that a
spec lead allay fears by adding some perspective, as in, "Don't
worry. We don't have to get through all of these issues by then, but
I think these pieces are most important. Does everyone agree?"
Looking Ahead
Because JSR 53 is subordinate to the J2EE 1.3 platform "umbrella
spec" JSR 58, neither the JSP spec nor the Servlet spec can go final
until all other specifications related to J2EE -- including
J2EE Connector Architecture 1.0 JSR 16 and Enterprise JavaBeans 2.0
JSR 19 -- are also
ready for release.
When the specifications go final, Pelegri and Coward are confident
they will be well-received. "Thirty heads are better than two,"
Coward still believes. "We work with very bright, very dedicated
people. If we can get this group to agree on the technology, we can
be pretty sure that we're doing the right thing." Since these key
industry leaders and book authors have been involved from the start,
the entire community can grasp and employ the technology more
quickly. "They understand the specification, they can evangelize it,
they can explain it, and they can quickly incorporate it into their
products," Coward says.
Eventually, the specifications will undergo another cycle of
revision. Already, the expert group has begun to think ahead to what
will be enhanced in the next versions. In terms of process, however,
Pelegri and Coward have decided to split up the expert group. "At
first, we thought it would be a bit easier on our resources to deal
with Servlet and JSP in the same expert group. For next time, though,
we've decided to divide into two separate expert groups," says
Pelegri, partly to reduce email traffic somewhat as well as to
forestall potential difficulties with persuading the Executive
Committee to approve such a unique setup.
|
" valign=top halign=center alt="JSR 53 Expert Group" vspace="10" hspace="10">