Authors: Robin Ruggaber (University of Virginia), Rob Sanderson (Stanford University)
Contributors: Claire Stewart, Michael Giarlo, Mark Bussey, Michael Friscia, Karen Cariani, Tom Cramer
Status: This document was adopted by Steering Group on 7th December 2014 subsequent to a community approval process. Minor changes to the first paragraph of "Working Group Requirements" on 24 July 2015 to remove the need for all WG participants to be covered by CLAs.
As the Hydra community grows, the diversity of the participants' interests and expertise is increasing at the same time as the ability to manage the work done within the community becomes more complex. It was noted at a recent meeting that even tracking what everyone is doing is a challenge, let alone ensuring that different organizations are not working independently on the same issue, or worse at cross-purposes. There is a strong desire amongst the participants to increase the visibility of their projects in order to encourage ongoing participation, and thereby prevent duplication of effort. To realize this goal, while remaining a distributed and peer-oriented organization, requires overlaying some additional structure to assist in coalescing and managing the tasks.
This document lays out a proposal for how to assert the least possible management structure while remaining effective. It is derived primarily from the experiences and guidelines of related organizations, including the W3C, the Research Data Alliance, and the Apache Software Foundation.
The solution must meet the following requirements:
It must not require a central organization
It must be lightweight enough that work is not prevented from being done
It must not promote any organization or individual as a decision maker over another
It must facilitate visibility and discovery of ongoing, beneficial work
It must not prevent other work from taking place outside of the structure
It must enable new participants to join in with ongoing development
It must encourage the development of products by the community
3. Proposed Solution
There are already self-organizing groups within the Hydra Community focused around various topics, either technical or domain-centric. The proposed solution is to embrace these existing interest/working groups and practices, but leverage the partnership mentality to ensure their success. By formalizing and providing guidance to this existing process, it is possible to increase the groups' visibility and likelihood of success, without imposing top-down order on a system that is, to a large degree, working well. That is to say, structure is not being imposed for the sake of having structure but guidance and assistance provided to enhance the benefits of emergent community best-practices.
Successful working groups will:
Be based on mutual respect
Entail a commitment to share expertise, effort and engagement
Be engaged with the Hydra community to ensure that requirements are first understood and then met
Develop high quality products within a reasonable timeframe that benefit multiple institutions, with an emphasis on those that participate in the development process
Encourage self-selection of participants, in a supportive, inclusive environment that fosters participation and contributions from throughout the community
These features suggest the following model of Interest Groups (IG) for surfacing the general areas of concern in the community and ensuring ongoing engagement with common topics and Working Groups (WG) for working together towards specific, agreed-upon results.
4. Interest Groups
Interest Groups, as compared to Working Groups, are for discussion rather than developing specific deliverables. It is expected that working groups will be formed out of interest groups as requirements emerge from the conversations.
Interest Group Formation
- IGs can be formed at will. A lightweight statement of the topic, the scope and objectives of discussion of the IG should be documented in the wiki, and at least one channel for communication noted.
- IGs do not need to be approved, but should not be formed without some level of need within the community.
- IGs may charter one or more WGs to accomplish specific objectives.
Interest Group Requirements
- At least three organizations must be represented in an interest group. Anyone may be part of an interest group with or without a CLA, as there are no deliverables from the group.
- All of the discussions of the interest group should be transparent and public and the channels used for communication must be published, but there may be situations where either the discussion takes place offline or is not suitable for public dissemination. These sorts of discussions are not expected to be common.
- Interest groups should be active, but may still exist when all of the participants are inactive - but see "sunset date" below.
Interest Group Dissolution
Interest groups can be dissolved if the participants decide that the topic has been explored. The wiki page describing the group should be updated to state this termination of the group and moved to the Interest Group archive. Groups should provide a "sunset date" after which its pages can be retired to the archive pages.
5. Working Groups
Working groups are the main working vehicle within the Hydra Community and may stand alone or be born out of existing Working Groups or Interest Groups. They are created to perform specific tasks in a defined realm and timescale, thereby allowing collaborative work to flourish in a structured environment.
Working Group Formation
Working groups should be able to be convened with a minimum of effort, while allowing participants to understand what they are signing up for. The group should emerge naturally from discussions and needs within the community, while not penalizing individuals or organizations that were not part of those initial discussions. Using existing channels, such as interest groups as described below, participants in discussions that show promise of inter-institutional convergence and the possibility of joint development work should document the shared needs and requirements. This documentation should be more persistent and visible than an email thread, but need not be overly formal. The preferred method is a maintained page within the Hydra wiki, otherwise a publicly shared document linked from the wiki is sufficient.
The documentation process should result in a common understanding of:
The overall domain into which the discussion falls
The shared needs and requirements within that domain
Use cases that demonstrate these needs and requirements
A path towards one or more products that would meet the requirements
The organizations willing to commit resources towards realizing the product(s)
The timeframe in which the product(s) are needed and should be possible - in particular, a "sunset date" should be specified
This document, henceforth the charter, provides the definition of the working group and its deliverables. It is not a contract and may be changed with the consensus of the members of the working group at any time, however significant changes such as a 6 month or more delay in timeframes, the abandonment of a deliverable, or the change in the overall scope of the work should be announced to the Hydra community via the regular channels.
Working Group Approval
Once the draft charter is acceptable to the participants in the discussion, there is a Call for Participation (CfP) issued. This is simply an email to the appropriate lists with at least [CfP] in the subject heading that announces the document and seeks the engagement of the additional participants. Organizations must respond publicly that they are willing to take part and commit development resources towards the working group's goals. At least three Partners must respond positively, and no more than three Partners may respond negatively, for the working group to be approved. If fewer than three Partners are willing to contribute, then the working group's topic is likely too specific and the work should be done outside of the Working Group process. If more than three Partners object to the work being done, then there is a significant issue that should be resolved before committing resources.
At least two calendar weeks must pass between the CfP and the working group being approved. If there are only one or two Partners interested after four calendar weeks, then the CfP is ended and the charter should be discussed and modified before re-announcing.
Once the working group is approved, the link to the charter will be added to the Hydra Wiki page that lists active working groups.
Working Group Requirements
All members of a working group producing software must be licensed Hydra contributors covered by the appropriate CLAs. This is to ensure that the software deliverables of the group are unencumbered by intellectual property restrictions. Participants meeting these requirements may join at any time, without any prior approval process: the gateway is activity, not reputation. Other types of contributions such as requirements, design, best practices, documentation, etc. - do not require CLAs but particpants should accept that the materials to which they contribute may be released under a Creative Commons Attribution-Share Alike 3.0 Unported License.
All discussion within the working group must be transparent. This means that meetings must have notes taken about the attendance and any decisions or action items, general discussions take place on mailing lists maintained by the community, IRC logs should be posted and so forth. Any meetings, face-to-face or teleconference, at which decisions are made must be announced in advance and open to any working group participant, otherwise any opinions expressed at the meeting must also be discussed on a mailing list. Meeting times should be published far enough in advance to allow members to schedule their participation, and preferably use a consistent schedule. The Partner institutions are responsible for ensuring the transparency of the discussion, but every participant is encouraged to take an active role in this regard.
Working groups must remain active. Any working group that does not respond to comments, questions or concerns either from participants or the community will be removed from the list of active working groups in the wiki.
Working groups must strive to meet their timelines and produce the deliverables designated in their charter.
The working group must always have at least one participant designated as Facilitator. Facilitators are responsible for promoting continued activity within the group. The Partner institutions are responsible for ensuring there is active facilitation, however the Facilitator is not required to be from a Partner. Facilitators have no additional powers or rights than any other participant.
Working groups may self-organize in the most convenient manner to accomplish their tasks, including creation and assignment of additional roles and responsibilities as appropriate. Sub groups may be formed and disbanded at will, consisting only of members of the Working Group. They do not need to separately meet the requirements of the Working Group, such as having their own Facilitator or Partner members.
Working Group Dissolution
Working groups are dissolved under the following circumstances:
All of the deliverables have been met. Hooray!
The group becomes inactive and its "sunset date" is reached
The group does not have participants from three or more Partners
The group does not have anyone willing to be the Facilitator
At such a time as a group is dissolved, it is moved from the active list of working groups into a working group archive page with the reason for its dissolution noted.
6. Community Channels
The following enumerate the current community channels for communication:
projecthydra GitHub repository
#projecthydra on Freenode
Following current best practices within Hydra, Working and Interest groups should use an existing channel unless and until it becomes clear that a dedicated channel is needed. If and when a dedicated channel is needed, the new channel should be well publicized and open to any interested subscribers/participants in the community. When using a shared channel, individual working groups should start the subject line with their name in s, such as [archives] for the Archives Working Group.