Because there is so much for new Spec Leads to learn, Bill Shannon of Oracle suggests finding a mentor. He says, "In the end, the best advice is to find another more experienced Spec Lead who's willing to answer your questions and give you advice."
Santiago Pericas-Geertsen of Oracle has found that the best way to learn the ropes of being a Spec Lead is to talk with more experienced Spec Leads.
You can read Specification Lead Profiles for more information on the Spec Leads of In Progress/Active JSRs.
As Spec Lead, Danny Coward of Oracle welcomes nearly anyone who wants to contribute and who adds value to the community and the technology. "I figured it was convenient to have all the people who cared about the technology in one place, so I would know what they all thought. That way all the fights, if there were to be any, were visible to everyone who cared," he says.
Technical know-how may not be enough reason to select someone to serve on an Expert Group. According to Marina Vatkina, "You need people who are passionate about the topic and who are willing to spend enough time to make the spec successful."
Ed Burns of Oracle thinks it's important to have the right balance of corporate and individual members on an Expert Group. "Ideally, among the set of active members, more of them should be corporate members than individual members. An 80%/20%, corporate/individual mix is about right. After all, individual members have the wide open world of open source in which to make their impact, while the role of the JCP is to ensure the steady and prudent evolution of the Java platform on which all of us rely," he says.
It takes a special sensitivity to take over an Expert Group that someone else started, and Jean-Yves Bitterlich of Oracle has been able to work out a process for doing that. When taking on the lead role for specifications in process, he respectfully takes any past resolutions decided by the Expert Group and uses those as the basis for finalizing the specification. He says, "Experience shows that efficient work and a satisfactory specification is reached by having prepared work and reaching consensus within the Expert Group."
David Nuescheler of Adobe Systems knows that scheduling can be a simple and effective tool. He says, "Short term deadlines are a Spec Lead's best friend to get the Expert Group focused."
Mitch Upton of Oracle is still learning what it means to be a Spec Lead. He suggests that all new Spec Leads write out a tentative timeline for their JSR that includes all JCP-mandated milestones and deliverables. He says, "I find this to be the most difficult administrative task to keep straight."
Make sure you also offer the necessary process time for these colleagues to converge well because, as John Rose of Oracle says, "Specifications are like software; they always take longer."
Pete Muir of Red Hat recommends keeping things as open and inclusive as possible. He says, "It's hard work, but you'll get a lot of useful feedback and help from the community."
Manik Surtani of Red Hat believes openness helps drive participation. He says, "Use public mail lists for 100% of your communication, and force Expert Group members to do the same. Hold regular meetings - perhaps on IRC so it can be 'recorded' for people who aren't able to attend - and publish the minutes online as well."
In his role as Spec Lead and Chair of the Executive Committee, Patrick Curran of Oracle believes in seeking consensus rather than adhering strictly to formal procedures. "It's important to allow all voices to be heard," he says, "and to make sufficient concessions to those who hold minority opinions that they don't feel they've been unfairly pressured. If you have to take a vote - even if you win that vote - then that's a sign you could have done better."
"The most important skill for managing an Expert Group is to ensure that everyone's views are heard by all members, leading to a specification that represents as close to a consensus as possible," says Doug Locke of The Open Group. And what if a topic appears to have reached an impasse? "Table it for at least a day and bring it up again later," he suggests. "The passage of time often brings about a softening of divergent positions."
According to Victor Grazi of Credit Suisse, "Spec Leads need to be both participants in and leaders of the JSR effort. He says, "Don't assume everyone will contribute; do your homework. Collaborate extensively, but then make the ultimate decision."
Roger Kitain of Oracle feels Spec Leads need to have good negotiation and decision making skills. If they don't have the skills, they can develop them by taking classes or by joining as a co-Spec Lead to learn from the other leader.
For new Spec Leads, Jacob Feldman suggests setting a personal high standard in three ways:
1) Treat the JSR not as a background activity, but as a serious software development project with multiple individuals/teams involved.
2) Develop at least one, but better two, implementations to accompany every specification phase from the very beginning.
3) Provide a TCK with different working samples, not only for the last phase, but rather as a parallel evolution with each specification release, starting with the very first one.
Ronald Toegl of IAIK understands that "For most of us in the Java community, it's more fun to write code than specification documents. So if you derive the specs from the code, the overall process becomes more creative, agile and enjoyable!" He advises Spec Leads, "Do not start with writing text, but work with Java code from the beginning. It's the perfect medium to develop an application programming interface (API). With tools like Eclipse you can easily refactor drafts into high quality APIs, and with JavaDoc you can automatically derive specification documents from it."
Ron Monzillo of Oracle recommends, "Create working examples of the use of your Java technology, in addition to the textual representations that occur in your specification."
John Rose of Oracle underscores what everyone knows: "Specifications without prototypes are idle dreams. Rework the prototype a couple of times, with the help of early adopters."
Linda DeMichiel of Oracle suggests working closely with the teams who are creating the RI and TCK. They inevitably notice any mistakes, ambiguities, or gaps in a specification, which they can relay to the Spec Lead for clarification. Although these kinds of questions may come up late in the process, Linda considers them essential to the process of refining a specification.
John Rose of Oracle considers good colleagues the single most important factor for success. He says, "Assume for the sake of argument that you are not already a one-man master of process, marketing, and technology. So lean on the complementary strengths of your management and peers at work, and on your (well-chosen) EG members. Even in areas where you already know exactly what's right, get the extra surprising insights that come from good colleagues."
Chris Vignola of IBM urges new Spec Leads to "leverage the industry knowledge of your Expert Group, enlist public involvement early and often, and collect the best ideas and build consensus."
Marek Potociar of Oracle warns new Spec Leads "to be prepared to start working really, really hard. It was very hectic time for me when I suddenly became a Spec Lead. The following ideas seemed to work for me."
- Get the best possible co-Lead for the spec. ("Santiago was a real win in my case," says Marek.)
- Avoid playing political games in the EG; just be open and honest, focusing on what's the best for the end user of the API in your proposals and discussions.
- Involve EG members as much as possible; present proposals as early and often as possible because their feedback is priceless.
- Talk publicly about plans for the spec as often as possible to get even more valuable feedback from the community.
- Find an experienced JCP Spec Lead mentor(s) to help deal with various issues that sooner or later appear.
|
