 
Use of JCP site is subject to the
JCP Terms of Use and the
Oracle Privacy Policy
 |
|
Development: Gathering Input from the Expert Group and Beyond
By Susan Mitchell
Excellent Java Specification Requests (JSRs) are developed in "community"-- with input coming from many directions to aid the Spec Lead in making decisions about the direction, scope, and content of a specification. Although the Expert Group in the Java Community Process (JCP) program is always the Spec Lead's primary source of input, JSRs that are developed in a transparent fashion also draw on the knowledge and experience of Observers, the Community, and the Public. The more voices that contribute, the greater the likelihood that the perspectives and interests of affected industries, developers, operators, and users will be addressed in a satisfactory manner. That diversity of input makes it more likely that the ultimate goal will be achieved: the specification will be adopted as a standard and implemented in products and services. Here are brief case studies of Spec Leads who are effectively gathering input from their Expert Groups and beyond:
When it comes to setting Java technology standards through the JCP program, Kay and Erkki really get the who of their assignment. Kay Glahn is working with Vodafone Group Services Limited and Erkki Rysa is a technology manager working for Nokia. As co-Spec Leads for JSR 249, Mobile Service Architecture 2 (MSA2), they realize the specification they release must satisfy not just their limited Expert Group but the needs and requirements of the whole community and Java ecosystem.
Kay notes that sometimes it is logistically and practically impossible to open up the Expert Group for everybody. "As in most open source projects, there are a limited number of committers and a lot of contributors who are also actively engaged in the project. Especially if the number of the Expert Group members is limited, it is important to encourage the community to get engaged in the transparently run JSR effort," he says. The Java community is a broad, diversely located group, so it can be hard to capture the simultaneous attention of a quorum. Nevertheless, Kay and Erkki feel that speaking directly to the community usually brings out the best input beyond the hand-picked Expert Group. Kay says, "Usually the community and especially small companies and individual developers who have a lot of specific knowledge about the mobile Java ecosystem do not have the time and resources to review lengthy spec drafts and meeting minutes in order to provide feedback. One-to-one discussions are the most effective way to get input and feedback from the community." "The EG can provide a lot of know-how and competence, but additional input is necessary from other players in the industry and more than welcome," says Erkki. In addition to their sessions on MSA at the JavaOne conference and their efforts to involve the community through panel discussions and other activities, Kay and Erkki run an observer mailing list that updates the community about current EG discussions. "We appreciate any feedback through our comment alias or the discussion forum on jcp.org or forum.nokia.com," Erkki adds. Until recently, one obstacle to transparency in the JSR 249 development effort was the lack of a public bug tracking system. Although the JCP program now makes Bugzilla available, Kay and Erkki didn't have that option when they set JSR 249 in motion and haven't yet had a good opportunity to revise their process. "Currently we mostly handle spec issues or comments and recommendations by email, but this information is not visible to the rest of the community. A public bug tracking system could make real time access to all that information transparent for the whole community. Hopefully we will be able to establish such a system soon for further feedback on MSA 2, which will be important for maintenance releases and future versions," says Kay. Gathering a well-rounded set of input is essential for making a JSR complete and getting it adopted. Kay says, "If the JSR fulfils the needs and tackles the issues of all players, the outcome will be a more complete spec that will be accepted and used by many more players."
Such a diverse Expert Group serves as a great starting point for getting ideas and opinions about the work in progress and influencing the look of the final spec. However, additional feedback is also critical. "Sometimes the Expert Group gets so buried in the specific details that it needs some outside feedback to make clear what is really important and what can be dropped," says Stefan, an IBM software architect working for WebSphere Portal and Lotus Web Content Management. Kurt Steubing, who is with the Emerging Technology Strategic Alliances part of the IBM Software Group, has seen Spec Lead transparency strategies evolve so that now JSR 286 has a plan that includes multiple channels for communicating and distributing information. "We have always fostered transparency. Over time, as we learned how to serve that need better, we have pursued transparency on more fronts," says Kurt. Stefan's team published frequent early drafts of the specification over the Internet to encourage broader feedback. In addition, they hosted the Reference Implementation (RI) on the Apache Software Foundation website as the Apache Pluto project (LINK to http://portals.apache.org/pluto/). This made it easy for everyone to get an early version and start reporting bugs. The Apache issue tracking system helped the team address the RI's known code issues. The comments that were gleaned from public reviews and through the usual mailing lists turned out to be useful in terms of insights into the requirements and general issues, but they were not delivered with the same detailed attention to quality as that provided by Expert Group contributors. Still, the final product can be expected to turn out best when there is a blend of both types of input. "For me, a good mix of a productive EG and public feedback is the best way to make good progress and still create a JSR that meets most people's requirements," says Stefan. For features that the EG itself felt ambivalent about, external feedback was especially useful. Those features were marked in the public draft and highlighted within a big box that specifically requested feedback. Comments on those particular items determined whether a feature was kept or dropped. Stefan and the other members of the IBM team are pleased with the resulting specification. In the spirit of continuous improvement, however, Stefan says of the JCP Program Management Office (PMO), "Next time I would use even more open collaboration tools, like public mailing lists, and I would look to the PMO to implement a voting website tool to assist Spec Leads with their JSR requirements."
"Expert Groups shouldn't be the only contributors to a specification. Feedback should be taken from the community of developers at large," says Mihir. "There are always developers out there who are getting their hands dirty writing code, and their feedback is extremely valuable. That makes the standards process truly transparent." With that aim, Mihir and Yannis created a Google group, sipservlets@googlegroups.com, for collecting JSR 289 feedback from the developer community as well as to give the Expert Group a means for offering clarifications on the specification and API. They posted an ad on the JSR 289 page to encourage participation. Membership in the Google group was open, and all participants had read/write privileges. The Google group forum was successful in allowing the Spec Leads to foster an open, many-to-many communication channel between the SIP servlets developer community and the JSR 289 Expert Group. Broad discussions of SIP Servlets technology as well as specific commentary on SIP Servlet Specification v1.1 took place in this forum. The Google group was also used to broadcast schedule changes and issue quick update messages. (An accurate schedule was also posted on the JCP Community Update page.) All the email discussions were archived, and issues that were resolved during the JSR 289 development were also published. In this way, the Expert Group members, most of whom were also members of the Google group, had full access to all JSR feedback, either automatically through the email list or through the archives. "The open membership on the Google group worked really well," says Mihir. He feels that involving more developers in the work of the Expert Group allowed them to drive adoption of the standard into the development community. And a standard that is adopted is a standard that is likely to succeed. The membership of the Google group grew to include 223 members, almost ten times as many as were in the original Expert Group. More importantly, the JSR benefited from the discussions and clarifications of some of the new features and APIs. Mihir says, "The discussions let us clarify the language in the spec or correct any anomalies in the API. There were questions ranging from usage patterns to implementing certain features, and so on. The Google group allowed anyone on the Expert Group to answer, not limiting the responsibility to only the Spec Leads." Sometimes the Expert Group preferred to have a separate place to make the nitty gritty decisions. Therefore, the Spec Leads set up an Experts-only discussion board Wiki that was employed for the discussion and tracking of issues. Because the mailing list of the sipservlets@googlegroups.com was so popular, the Expert Group didn't get many comments through the standard jsr-289-comments@jcp.org mailing list. Moreover, as Mihir recalls, the latter list was read-only, and only Spec Leads could post. Mihir and Yannis wish that the JCP program at that time had provided software that would track tasks delegated to Expert Group members, track issues reported by the community and their resolution, and collaborate on proposals using Wikis. All of those options, through the Wiki and Bugzilla, are now offered to interested Spec Leads on the jcp.org website. Since those were not available at the time, Mihir and Yannis created a public website to host the collaborative software CodeBeamer from Intland Software. "This was done at our own expense of hosting and maintaining the software," says Mihir. "This collaborative software gives a better handle for managing a large EG and big specification." Intland actually wrote up a success story relating the Expert Group's use of their software. These Spec Leads were successful in their pursuit of community input and in finding creative solutions to problems they encountered. They removed obstacles and barriers, making it easy for everyone make contributions to a more robust technology.
|
