Kepler Management Charter

Mission

The Kepler Project is dedicated to furthering and supporting the capabilities, use, and awareness of the free and open-source scientific workflow application, Kepler.  Primary responsibility for achieving these goals lies with the Kepler Project’s Leadership Team, which will work to assure the long-term technical and financial viability of Kepler by making strategic decisions on behalf of the Kepler user community, as well as providing an official and durable point-of-contact to articulate and represent the interests of the Kepler Project and the Kepler software application.

Scope of Activity

Kepler Project Management

The Kepler Leadership Team acts to preserve and strengthen the open nature of the Kepler project, including its use of an open source model of software development and release.  The Leadership Team creates and maintains an organizational structure that enables coordination of the contributions of a large number of distributed projects and individuals, each of whom brings different interests, priorities, and funding to their work. The Kepler Leadership Team has ultimate responsibility for managing all aspects of the Kepler Project, and ultimate authority for making all decisions and organizational changes needed to ensure the long-term technical and financial success of Kepler.

Responsibilities of the Leadership Team include but are not limited to:

• determining the structure and function of the Kepler Project
• approving Infrastructure Team, Development Team, and Interest Group charters
• making decisions about strategic project directions
• authorizing the official inclusion of components in Kepler releases
• resolving conflicts among Kepler contributors if these arise

The Leadership Team helps guide and facilitate the overall design and development of Kepler through member participation in other Kepler operational structures, such as Infrastructure and Development Teams, and through conflict resolution.

The Leadership Team has the sole authority to make the decision whether to pursue establishing a non-profit legal entity to represent the Kepler Project.

Management Team Composition

The Leadership Team consists of 6-8  individuals who have committed to act in the best interests of the Kepler Project.  Members of the Leadership Team will represent a variety of contributing institutions and will have exhibited a long-term dedication to Kepler and its goals and have a deep knowledge of the project, the needs of various user communities, and technology used within Kepler.

Members of the Leadership Team will nominate and elect from amongst themselves (by the voting process described below), a Chair and Secretary, each for a term of one year, with no term limits.  The Chair will preside over meetings of the Leadership Team, serve as the public representative for the Kepler Project, and represent the actions and activities of the Leadership Team to the public and Kepler user community.  The Secretary will assist the Chair and Leadership Team in scheduling and planning activities such as Leadership Team Meetings, and serve as the official recorder of the issues and outcomes of these activities.

Leadership Team members serve for terms of 3 years, with renewal for additional terms possible upon an approval vote of the remainder of the Leadership Team using the voting procedures described below.  When members are to be added,  e.g., if membership falls below six, the Leadership Team will issue a call for nominations to gather background materials on potential replacements and will evaluate candidates for their demonstrated commitment to the Kepler project, their past organizational and technical contributions, and their background and skills in managing a technical project like Kepler. The Leadership Team will then vote to approve nominated members using the voting procedures described below.

Leadership Team Decision Process

The Leadership Team will make most decisions based on general agreement among the entire team based on open discussion of issues and background information relevant to the decision.  In general the Leadership Team will attempt to act based on unanimous consent, and will resolve conflicts that arise in the conduct of Kepler projects in a fair manner that is equitable to all parties involved. 

In cases where an issue of major strategic importance to Kepler has arisen or when agreement cannot be reached among Leadership Team members, a formal voting process will be employed that gives each team member one vote.  Any Leadership Team member or member of the Kepler community can raise a proposition for the team to vote upon. The Leadership Team can meet in person or use various remote conferencing systems to discuss and vote on propositions put before it by members of the Leadership Team, or introduced by another member of the Kepler community. A quorum in which propositions can be put forward and voted upon will be in effect if two-thirds of the Leadership Team members are in attendance physically or via conference system.  Votes by Leadership Team members can be cast in absentia by email within three weeks of the meeting at which any proposition was discussed and voted upon. The Secretary will record the date and text of all propositions and voting results and will archive this information in an accessible place for the Leadership Team members to examine.

For each proposition raised to the Leadership Team, votes can be cast to "Approve" the proposition, "Disapprove" the proposition, "Veto" the proposition, or to "Abstain".  Propositions will pass muster with more than a simple majority of "Approve" votes and no "Veto" votes.   An "Abstain" vote is used to indicate that the member is either unqualified to vote (e.g., in the case of complex technical decisions outside of their expertise) or have no opinion.  A "Disapprove" vote indicates that the member disagrees with the proposition, but not enough to attempt to block its passage with a Veto.  The "Veto" vote is an indication from a member that they disagree with the proposition enough that their single vote blocks its passage in order to allow further time to discuss and develop alternatives that benefit the Kepler project.  "Veto" votes must be followed by a rationale that explains the issues to be resolved by the Leadership Team. When one or more Veto votes are cast along with a simple majority of Approve votes, the proposition does not pass; the members who cast Veto votes must send out a rationale statement explaining their objections to the rest of the Leadership Team within 2 business days; and a second vote must be scheduled within 10 business days on either the identical proposition, or a modified form of the proposition.  For identical propositions, a supermajority consisting of more than 2/3 of the Leadership Team is required to pass the vote and override any remaining Veto votes; if a supermajority is not achieved, then the proposition does not pass.  Modified propositions start the voting process over as if they were new propositions.

Organization of Kepler Contributors

The Kepler Leadership Team creates and oversees three distinct types of groups for supporting diverse contributions from a large number of people and projects: Infrastructure Teams, Development Teams, and Interest Groups.  These groups focus on particular functional or topical aspects of Kepler, at different levels of generality and commitment.

• Infrastructure Teams identify, discuss, design, clarify, and implement critical aspects of the Kepler framework and development infrastructure used by the entire Kepler community, and that are fundamental to the Kepler platform.
• Development Teams design, develop, and test specific products or deliverables for use by the Kepler Project
• Interest Groups communicate about and collaborate on particular, potentially specialized capabilities and functions for Kepler to meet the needs of a stakeholder community. 

Infrastructure Teams and Development Teams

Participants can form a Development Team to develop a specific product or deliverable for Kepler. This can happen de novo, or arise when discussion within an Interest Group has become focused enough to define specific products that merit implementation. Every Infrastructure Team and Development Team operates under a charter that clearly states its mission and scope, and lists the current chair and participants as well as the procedures for participants to be added and removed from the team. Each Infrastructure and Development Team must also maintain a roadmap documenting its plans for design, development, testing, and release of products in its mission area.  These documents will be presented in a consistent and easy to comprehend manner on the Kepler web site, making it clear which Infrastructure Teams and Development Teams exist, the purpose of each, and who are the participants in these efforts. In overseeing the development of Kepler, the Kepler Leadership Team authorizes the activities of these organizational units, and takes responsibility for evolving this organizational structure in the long term as needed.

The number of Infrastructure Teams and Development Teams is not fixed.  New teams can be proposed and the participants in each can vary over time.  Each team must have a designated chair who is responsible for organizing the activities, for recruiting participation in the team, and coordinating contributions to Kepler by that team.  A chair is identified at the time that the team's charter is created, and is typically determined by the people proposing the team, with the approval of the Kepler Leadership Team. A particular team can be expected to have periods of intense operations, and other periods of dormancy with most work going into maintenance of the team's products.  Several other open source projects follow this model of organized subprojects (e.g., Eclipse, Apache, Mozilla).

Infrastructure Teams sustain the development of the overall system and maintain the kernel of Kepler on which all other subsystems can build. The broad Kepler community is invited to participate in these core Infrastructure Teams to help drive development of the Kepler platform, although we expect the Kepler framework and build system to change more slowly than community-specific extensions developed by Development Teams.

Development Teams design, develop, test, and deploy the software and infrastructure necessary for a specific functional extension, domain-specific extension, or actor package for Kepler, or for other related products. As described above, each Development Team operates under a charter that identifies its chair, mission, and scope; and a roadmap that identifies its current work plan and planned products. To create a new Development Team, a potential chair must assemble and submit its charter, roadmap, and initial participant list to the Kepler Leadership Team, which reviews, edits, and approves the Activity.

Creating Infrastructure Teams and Development Teams

Forming an Infrastructure Team or a Development Team involves accomplishing the following tasks:

• creating a Charter that explains the scope of the area of shared interest and follows a format approved by the Leadership Team

• identifying a person to chair the activity and organize other participants.
• developing a non-binding Roadmap outlining any deliverables to be produced
  

These documents are then submitted to the Leadership Team for review.  The Leadership Team will either approve the Charter and formally launch the team, or will provide comments for revising the documents for later resubmission. Individuals who wish to create a team can request a project space in the Incubation areas of the Kepler web site to assist in the construction and submission of their documents.  When approved, teams in Incubation will be moved to the appropriate Infrastructure Team and Development Team areas of the site.

Interest Groups

Interest Groups provide a mechanism for communicating about and collaborating on particular, potentially specialized capabilities and functions for Kepler to meet the needs of a stakeholder community.  Interest Groups are formed by approval of the Leadership Team when an Interest Group chair submits a brief Statement of Interest representing two or more individuals with a common interest in a functional area or topical area related to Kepler that they want to discuss or communicate about in a loose fashion.  Forming an Interest Group provides the users with a collaboration mechanism through the various collaboration tools and services provided by the Kepler Project, and provides a mechanism for others interested in the same topic to discuss and contribute.  Interest Groups are intended as a lightweight mechanism for community members to discuss areas of common interest, and are easy to form: the chair of the proposed Interest Group should submit a short paragraph description of the group to the Leadership Team, upon which a member of the Leadership Team will create the group in the Incubation area and forward the request for review by the overall Leadership Team.  The Interest Group can then start using the collaboration tools in the Incubation area while the Leadership Team reviews the Interest Group request to verify that it is within scope of the Kepler Project and that it doesn't substantially duplicate other Interest Groups.  Once approved, the Interest Group collaboration site will move out of the Incubation area on the web site and into a permanent location. If Interest Groups identify specific products they want to collaborate on developing, they can propose a Development Team to do so.