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
The Enhydra Working Groups form a simple hierarchy, where the 'Architecture' WG is the parent or master WG and all the other groups fall directly under it (For more information on each group, follow the link.).
- Architecture
- Kernel
- Services
- Shared Technologies and Standards
- Tools
Definition of a Working Group
A working group shall exist for each standalone subsystem or particular system-wide protocol (such as Security or Management) that is part of the overall Enhydra runtime system, or one of the tools used in the development or maintenance of Enhydra applications. Each working group should be largely autonomous, and should only need to interact with other working groups when functionality overlaps multiple groups.
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
The community, as well as the internal Lutris development team, can suggest additional working groups. New groups must be suggested through a proposal to the Enhydra general mailing list, or to one of the working group mailing lists. The proposal should include detailed reasoning as to why a new group is needed, as well as why existing groups are not sufficient. If the proposal is submitted to a specific working group, it should be "bubbled up" to the main Enhydra mailing list.
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
In the event that a working group is felt to be of little or no use to the community, an email stating the perceived problems of the group, as well as noting its inactivity, should be sent to the working group mailing list. These mails should only be sent by another chair of a working group, or a voting member of the Enhydra community, in an effort to keep the communication professional and courteous.
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
Every working group in the Enhydra Community consists of at least the following components:
- Chairperson
- Selection of Chair
- Change of Chair
- Responsibilities
- Introductory Paragraph
- Home Page
- Description
- Features
- Mailing List Information
- Working Group Documentation
- Chair Contact Information
- Anonymous Read Access to Source Code through Web Browser
Chairperson
The Chair is the owner or chairperson of the working group. The Chair is an expert in the particular technology the subsystem represents. The Chair may or may not be an employee of Lutris Technologies. In general, the Chair is responsible for the online content, community feedback via mail lists, and representation for their own working group subsystem. Specifically, the Chair is responsible for providing the online content, downloadable (ftp) documentation content, moderating the working group mailing list, creating and maintaining the subsystem requirements, representing the WG on the master (Architecture) WG, code submissions to the main CVS tree (check-ins), bug submission triage (priority) and assignments of tasks that need to be done to volunteers. Currently, the actual posting of content, ftp posting of files, management of mail lists, CVS source accessibility must all be done through the enhydra.org webmaster.
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
The chair is an integral part of a working group, and must be determined at the time of creation of a new working group (if not before). If a community member has a suggestion for a specific chair of a working group, that person should be named in the proposal for the working group. The chair is the only portion of a working group that may be modified from a proposal without explicitly changing and re-voting on the proposal (for example, a working group proposal may be accepted, and the chair changed, without having to re-vote on the entire proposal). The chair should be selected through a general consensus. If there is great disagreement, voting can be used for selection of the chair; however, in most cases an acknowledgement that one individual is the right person for chair is enough, and preferred. This avoids the awkward case of having to "-1" a community member when a stricter voting policy is used.
Change of Chair
The chair may at any time "step down" due to a lack of time or resources for committal to the working group. At this point, the chair should recommend and endorse another member (preferably a committer of the community and working group in particular) as the new chair. Again, general consensus is enough for this new person to be the chair. If within 30 days of the current chair stepping down, no new chair has been identified or approved, Lutris Technologies will select a chair and put forth that person for approval in the community (again, by general consensus, as opposed to strict voting). This implies no rights of ownership to Lutris, but does ensure that a working group is not dissolved due to lack of activity, simply because no chair is in place to drive the group.
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.
Responsibilities
The chair's primary responsibilities are not necessarily technical ones. While the chair should be an expert in the technical subject their working group is responsible for, the chair must drive the group. Typical means for keeping momentum high in the group include posting links to relevant articles (for example, the Architecture chair might note a new W3C specification affecting XML use in messaging), writing short "mini-articles" designed to elicit thought and feedback, comment on code, and generally keep people interested. This momentum is one of the key necessities in the working group, as a lack of momentum often signals a lack of interest and can result in a loss of resources.
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.
Introductory Paragraph
The introduction is a concise one-paragraph description of the working group that differentiates it from other groups. Currently, all of these are organized at the main Working Groups page. A community member should be able to read this paragraph and understand the purpose of the group, as well as know what technologies are involved in the group (for example, it should be clear from reading the introductory paragraph on Brock that HTML, XMLC, and servlets are involved).
Home Page
Each working group will have a central area of "web real estate" in which to supply documentation, details about the group, and other relevant information. The page should at a minimum contain the components below.
Description
A complete description of the working group should be included on the page. This will often include the introductory paragraph, but should also contain more detailed information about the group. Short- and long-term goals for the group should be outlined, a summary of current progress towards those goals should be included, and a general direction should be provided. If specific APIs or specifications are being implemented, they should be at least mentioned here (although detail can be included in the features section).
Features
The group should have a complete list of the sub-project's features. At a minimum, this should include all APIs and specifications that the working group is either supporting or working to support (for example, Sun J2EE, Apache SOAP, JDOM, W3C Namespaces, etc.). This aids in clarifying exactly where the working group is moving, and showcases Enhydra's commitment to standards.
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 has a mailing list associated with it. The home page for each group should have links that allow anyone to join the mail list and to view the mail list archives online. The email address naming convention for each working group mail list is "
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
Links to Functional Requirements documentation for each subsystem directly related to a working group are to be posted on the group's web page. These files are currently updated by the enhydra.org webmaster as requested by the working group Chair. Documentation can be submitted by the community to the mailing lists, and can be requested to be put online. The working group Chair will determine if the document(s) is appropriate for posting, and make it available online if possible. If there are problems with the document that prevent it from being posted, these problems will be related to the original submitter, and if changes can be made that would allow posting, the submitter may make these changes. Additionally, credit to the author of the document should be given on, at a minimum, the title page of the posted document.
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
Information should be made available by the Chair which allows easy and quick contact. This will include, at a minimum, the Chair's full name and a direct email address. This can be either a business or personal email, but must be accessible by the chair at all times during the day, to ensure the availability of prompt responses. The chair may also post address information (for mailings, when needed), but a telephone number is discouraged, as it supports direct contact, when mailing list contact (in a public forum) is preferred.
Anonymous Read Access to Source Code through Web Browser
CVSWeb should be made available to the working groups and their communities. For each working group page, a link to the portion of the Enhydra CVS tree that the project is concerned with should be provided. This should only be a link to the master CVS tree (in CVSWeb format), rather than a copy of the tree, to avoid splintering or confusion regarding the relationship of the project's code to the overall Enhydra codebase. Standard CVSWeb practices will be followed.
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.
