The Integrated Software for Imagers (ISIS) Technical Committee will operate transparently, openly, inclusively, collaboratively, and ethically. Project proposals, timelines, and status must not merely be open, but also easily visible to outsiders.
Most large, complex open source projects have a community of motivated
contributors and a set of supporting policies that describe how the
community strives to operate (e.g. the technical governance model).
Technical leadership for the ISIS project is the Technical Committee (TC).
The ISIS project's contributor community are all of those participants making
substantive contributions.
The TC's role is to set policy, carry out those responsibilities detailed in this Charter, and potentially mediate charged or contentious concerns between contributors. The contributing community takes overall technical ownership of the project and are the 'doers' that get the tangible work done that users depend upon. The contributing community and TC work together to define, maintain, and uphold the community norms. The TC will codify those norms as project policies to ensure shared expectations.
TC memberships are not time-limited. There is no maximum size of the TC. The size is expected to vary in order to ensure adequate coverage of important areas of expertise, balanced with the ability to make decisions efficiently. The TC must have at least three members.
There is no specific set of requirements or qualifications for TC membership beyond these rules. The TC may add additional members by consensus. If there are any objections to adding any individual member, an attempt should be made to resolve those objections following the Consensus Seeking Process. A TC member may be removed from the TC by voluntary resignation, or by consensus of all other members.
Changes to TC membership should be posted in the agenda, and may be suggested as any other agenda item.
If an addition or removal is proposed during a meeting, and the full TC is not in attendance to participate, then the addition or removal is added to the agenda for the subsequent meeting. This is to ensure that all members are given the opportunity to participate in all membership decisions. If a TC member is unable to attend a meeting where a planned membership decision is being made, then their consent is assumed.
No more than half of the TC members may be affiliated with the same employer. If removal or resignation of a TC member, or a change of employment by a member, creates a situation where more than half of the membership shares an employer, then the situation must be immediately remedied by the resignation or removal of one or more TC members affiliated with the over-represented employer(s).
The TC may, at its discretion, invite any number of non-voting observers to participate in the public portion of TC discussions and meetings.
The TC shall meet regularly using tools that enable participation by the community. Minutes, or an appropriate recording, shall be taken and made available to the community through accessible public postings.
TC members are expected to regularly participate in TC activities.
In the case where an individual TC member -- within any three-month period -- attends fewer than 25% of the regularly scheduled meetings, does not participate in TC discussions, and does not participate in TC votes, the member shall be automatically removed from the TC. The member may be invited to continue attending TC meetings as an observer.
The TC is responsible for defining project scope and codifying technical policies in support of the contributors to the ISIS Software Project. Responsibilties include the development and maintenance of policies and procedures to support:
- Release processes (including setting release cadence and release quality standards).
- Project governance and process (including this policy).
- Location of the official software repository.
- Conduct guidelines.
- Maintaining the list of contributors.
- Contribution guidelines (including coding and testing standards).
- Mediating technical conflicts between Collaborators.
The TC will define the ISIS Software Project's release vehicles and serve as ISIS Software Project’s primary technical liaison body with external open source projects, consortiums and groups.
The TC will establish and maintain a development process for the ISIS Project. The development process will establish guidelines for how the developers and community will operate. It will, for example, establish appropriate timelines for TC review (e.g. agenda items must be published at least a certain number of hours in advance of a TC meeting).
There will be multiple Projects under the ISIS Project organized by modules or subsystems. The TC is responsible for organizing the Project structure, including possibly the creation and alignment of sub-Projects. Each Project must be within such policies as may be set by the TC, have a well-defined scope and must work within that scope. The development process will provide a lifecycle process for Projects to follow as described in the Project Lifecycle document. The development process will include a process for the TC to oversee and approve changes in the lifecycle of a Project, which will include consideration of the following criteria:
- Cleanliness of code base
- Ample and diverse Contributors and Collaborators to assure vitality of the project.
- Stability (e.g. presence of test suites, stable APIs and use of an appropriate source-code control system).
- Predictability of releases
- Alignment with ISIS Software Project’s goals and priorities.
The contributing community will follow any processes as may be specified by the TC relating to the intake and license compliance review of contributions.
For internal project decisions, Collaborators shall operate under Lazy Consensus. The TC shall establish appropriate guidelines for implementing Lazy Consensus (e.g. expected notification and review time periods) within the development process.
The TC follows a Consensus Seeking decision making model. When an agenda item has appeared to reach a consensus the moderator will ask "Does anyone object?" as a final call for dissent from the consensus.
If an agenda item cannot reach a consensus a TC member can call for either a closing vote or a vote to table the issue to the next meeting. The call for a vote must be seconded by a majority of the TC or else the discussion will continue.
For all votes, a simple majority of all TC members for, or against, the issue wins. A TC member may choose to participate in any vote through abstention.
The TC shall set the policy for where the official software repository should be maintained.
Individuals making significant and valuable contributions, “Contributor(s)”, are made Collaborators and given commit-access to the project. These individuals are identified by the TC and their addition as Collaborators is discussed during the monthly TC meeting. Modifications of the contents of the Git repository are made on a collaborative basis as defined in the development process.
Collaborators may opt to elevate significant or controversial modifications, or modifications that have not found consensus to the TC for discussion by submitting a pull request to the next TC meeting agenda. The TC should serve as the final arbiter where required. The TC will maintain and publish a list of current Collaborators by Project, as well as a development process guide for Collaborators and Contributors looking to participate in the development effort.
-
Contributors: contribute code or other artifacts, but do not have the right to commit to the code base. Contributors work with the Project’s Collaborators to have code committed to the code base. A Contributor may be promoted to a Collaborator by the TC. Contributors should rarely be encumbered by the TC and never by the ASC Management Team.
-
Project: a technical collaboration effort, e.g. a subsystem, that is organized through the project creation process and approved by the TC.