[jsr-314-open] revisiting the JSR-314 openness policy

Several EG and community members, myself included, have requested--directly or indirectly--for the openness policy of JSR-314 to be revisited. We are concerned that the original goals have not been fully met and, therefore, are not yet satisfied with the situation. Certainly, the opening of the EG mailinglist for viewing by subscribers is a step in the right direction, but it does not embrace the level of openness that properly respects the community's role and expertise nor does it effectively attract new participants. *It's also important to note that the web archives stopped working in late June.* We never addressed two key requirements that were identified and agreed on in a previous thread (see http://archives.java.sun.com/cgi-bin/wa?A2=ind0904&L=JSR-314-OPEN&...): 1. We need a list focused on specification discussion that is readable/writable by the public. 2. The lists we use should be indexable/accessible without requiring a login . Our first choice for request #1 is to allow all subscribed members of the jsr-314-open list to post, with moderation of a person's inaugural post (webbeans-dev uses this approach, for instance). The second choice would be to have a separate list open to the community. In either case, both lists should satisfy request #2. The current solution, the jsr-314-open mailinglist, does not address either of the above two requirements. (It's even difficult to reference a thread, as indicated by the supporting link). Additionally, having a moderator forward messages from the jsr-314-comments e-mail alias is also a flawed arrangement. It causes extra work for the moderator and confusion on behalf of the sender, the latter of whom gets locked out from participating in the discussion he or she originates. To muddy the waters further, the newly overhauled JCP site offers EG-specific forums, JSR-314 included, that are open to the public: http://wiki.jcp.org/boards/index.php?b=958 The forums meet the requirements above, with one possible exception. Based on initial evaluation, it appears that the e-mail bridge, if it exists, may not be enabled. I think we can all agree that having an e-mail bridge is an implied requirement. Let the following response by Jim Driscoll to an inquiry on the java.netforums about whether there are public discussion boards for JSF ( http://forums.java.net/jive/message.jspa?messageID=358786) provide motivation to revisit the openness policy: I'd love to have more actual users involved in the discussion of future Clearly the read-only nature of the jsr-314-open list is acting as a barrier to participation. It puts more work on the shoulders of EG members to carry discussions back and forth, in the style of the game Telephone ( http://en.wikipedia.org/wiki/Chinese_whispers), which we all learned in grade school quickly degrades the accuracy of the initial message. As a result, a potential improvement to JSF dissolves. I'd like to provide clarifications about the agreements that were made at JavaOne that Ed cited in the forum post referenced above. 1. jsr-314-open(a)jcp.org is read only to non-EG members. Non-EG members can Regardless of whether we have one list or two, we need somewhere for community members to post in an unrestricted manner. Currently, the community still has no unmoderated voice in the form of a mailinglist. 2. Feedback should be sent to jsr-314-comments(a)jcp.org. This list is This is a stopgap solution until we can have a real community feedback channel. Forwarding messages is just messy and doesn't give the sender a chance to participate. As usual, anyone can apply to be on the EG once they join the JCP, but We should not consider individual JCP members as lesser participants than organizations. Every participant in JSR-314 should be treated with equal weight, regardless of whether they are John Smith, Barack Obama or Acme, Inc. Based on past discussions, the two changes to the openness policy of JSR-314 that were stated at the beginning of this message seem to have general support from EG members. Does anyone have objections to these goals? If not, are there specific barriers that we need to overcome to make this happen? Ed, Roger - do you have suggestions for how best to pursue these goals? -Dan -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://mojavelinux.com http://mojavelinux.com/seaminaction http://www.google.com/profiles/dan.j.allen