Enhydra Community Process: Working Groups
The basic "building block" of all Enhydra development is the working group. Because of the size of the project, breaking development into discrete, managed modules allows better organization. This also allows community members with interests in only one area of the project to focus on that area without receiving excessive information about other areas. The working group processes are outlined here.
Working Group Organization
Definition of a Working Group
It is the responsibility of the chair, in particular, and the group, in general, to redirect mailings that are more suited for other groups. For example, a lengthy mail detailing class loaders in relation to EJBs that is sent to the Architecture group should be either copied or forwarded on to the EJB working group, either by the chair of the Architecture group, or by another member of the group that is on both the Architecture and EJB working group (assuming the individual is subscribed to both, so postings do not bounce).
Creation of New Working Groups
Once the proposal has been submitted to the Enhydra list, all voting members of the Enhydra community may vote upon the proposal. See Voting for details on the voting process. Any negative votes (-1) must be accompanied by a reasonable explanation, and preferably an alternative to the need the proposal attempts to fill, or they will be discarded. If a consensus is reached (three or more +1 votes), the new working group will be created.
Dissolution of Working Groups
Upon receipt of the mail, the working group shall be put under evaluation for thirty days. If after thirty days no significant activity or reasoning for keeping the group is shown, the dissolution of the group shall be put to a vote on the general Enhydra list. For this vote, a consensus must be reached (three or more +1 votes, and no -1 votes). However, the chair of the working group proposed for dissolution may not cast binding votes. While he or she may vote in order to be heard, that vote does not affect the overall vote count, in the positive or the negative. This should negate any effects of loyalty or prejudice that the chair may have incurred in leading the group. If the vote reaches a consensus, then the working group will be dissolved.
All working group emails and correspondence, as well as documentation, will be maintained. Additionally, the chair of the working group will work with the other working group chairs, and find a group that can subsume the documentation of the dissolved working group. For example, if the Enhydra Director group were dissolved, its documentation and archives would most logically reside within the Management working group.
Components of a Working Group
Note: Moderation, in this context, refers to monitoring and avoiding flame wars, commercial postings, and junk mail. It does not, in any case, refer to blocking mails that are negative or otherwise unsavory. The Enhydra mailing lists are completely open, and should be used as a forum for all comments, even if they are critical or negative.
Selection of Chair
Change of Chair
Additionally, if members of the Enhydra community and the working group in particular, or chairs of other working groups, feel that the working group's chair is not sufficiently aiding in the efforts and driving the processes in the working group, they should approach the chair privately (preferably by voice contact [phone or in person], but at least by private e-mail). If the issues cannot be resolved, the chair of the Architecture group (the primary working group) should be approached, and the problems laid out. At this point, the Architecture chair will determine if a new chair is needed, and take the appropriate action, which may involve no action, speaking to the chair, putting the chair into a "probationary period" to evaluate their effectiveness, or asking that a new chair be selected. All of these items should be handled privately be the chair, as to cause the least amount of personal embarrassment and community visibility.
If the problem in the chair arises at the Architecture working group (with no other chair to offer recourse), the concerned parties should contact the Enhydra Strategist, who is specifically responsible for open source issues and community involvement, and explain any problems. Additionally, general questions or concerns that are less serious, but not fit for public review, can always be directed to the Enhydra Strategist for advice.
Additionally, the chair is the ultimate authority for patches and code submissions. All patches, as well as CVS checkins by project committers, should be reviewed by the chair. Any problems with builds that result from code checkins, as well as compliance tests that break, ultimately rest with the chair. This "single point of responsibility" ensures that a minimum of finger pointing and blame occurs, particularly at new members of the community who are unsure of how to get involved, and may make mistakes. The chair is also responsible for keeping track of submitted patches; the chair should answer any requests for a status on a patch promptly.
Additionally, any proprietary features of the Enhydra implementation should be listed; for Brock, this might include information about what version of XMLC is used, what enhancements are contained within Brock, etc. For Architecture this might include details about the pluggable architecture and how services can be created by end-users.
Mailing List Information
Each working group chair is also a member of the Architecture working group and is responsible for representing their own subsystem on the Architecture mail lists, and in Architecture decisions that will affect (directly or indirectly) all working groups. Each Chair should re-post email sent to the Architecture mail list that is pertinent to their subsystem and ask for feedback. The email thread should continue on both the Architecture and sub-working group mail lists for as long as it is appropriate. Often, to avoid multiple-list emails, a discussion may need to be taken to a working group until consensus is reached, and the resulting ideas taken back to the Architecture group.
Working Group Documentation
Each Chair is responsible for posting relevant documentation on their home page. Also, each Chair is responsible for requesting links to other working group documents that are relevant to their subsystem. These should be links, rather than reposts of the same document. The standard file format for posting is .PDF files in order to enable cross-platform viewing, and easier online reading. If a PDF writer is not available in the case of community submissions, it is the responsibility of the Chair to convert the document; Lutris Technologies will provide this service if the Chair is unable.
Chair Contact Information
Anonymous Read Access to Source Code through Web Browser
A short section on the main enhydra.org website should be provided detailing the use of CVSWeb, and also explaining the frequency of updates to the online, browse-able source code.