This page describes the Project Steering Committee of iota2. It is inspired by OTB Project Steering Committee.
- PSC scope
- How does the PSC work?
- Current members and roles
The aim of the iota2 Project Steering committee (PSC) is to provide high level guidance and coordination for the iota2 project.
It provides a central point of contact for the project and arbitrates disputes. It is also a stable base of "institutional knowledge" to the project and tries its best to involve more developers and users.
It should help to guarantee that iota2 remains open and company neutral.
The PSC gathers and publishes high level roadmaps for iota2:
- Feature roadmap,
- Technical roadmap (developer and coding guidelines and workflows, target systems, packaging ...),
- Infrastructure roadmap (SCM, wiki, dashboard ...).
The PSC also publishes the guidelines and the acceptance policy for feature requests. It enforces them. It monitors and approves new feature requests.
The PSC coordinates communication actions:
- Ensures that the on-line information about iota2 is up-to-date and proposes new content,
- Keeps track of opportunities to communicate: Symposium and events where iota2 could be represented,
- Keeps track of opportunities from communities: Google Summer of Code project, link with other OSGeo and FOSS projects,
- Is responsible for the organization of events around iota2 (i.e. users meetings and hackathon).
User support and documentation
The PSC ensures that users are given an appropriate support:
- Ensures that support is working (unanswered questions, questions from other places than the gitlab issues ...)
- Proposes addition to the documentation based on users feedback,
- Proposes new features for the roadmap based on users feedback,
- Proposes new ways for support and documentation.
The PSC publishes the guidelines and acceptance policy for contributions. It enforces them.
It monitors and approves new proposals.
It ensures that contribution is as easy as possible, by monitoring technical means for contribution and proposing evolution to guidelines, policies and means.
The PSC publishes release guidelines and policies, and enforces them.
The PSC puts together the next Release roadmap and proposes a planning. It is then responsible for the release preparation.
The final approval for a release is given by the PSC.
Handling of legal issues
The PSC is responsible for addressing any issue about copyright or licensing that may occur, and most importantly, it is responsible for taking preventive actions about those issues.
How does the PSC work?
This section describes how the PSC works.
All members have equal standing and voice in the PSC. The PSC seats are non-expiring. PSC members may resign their position, or be asked to vacate their seat after a unanimous vote of no confidence from the remaining PSC members.
The expectations on PSC members are:
- Be willing to commit to the iota2 development effort (code, documentation, training),
- Be responsive to requests for information from fellow members,
- Be able and willing to attend on-line meetings,
- Act in the best interests of the project.
It is important to note that the PSC is not a legal entity.
Members can be assigned roles corresponding to each category of the PSC scope described above.
Being assigned a role does not mean undertaking all necessary actions, but rather ensuring that actions will be undertaken.
In addition to their specific roles, members of the PSC commit to participate actively in discussions and votes.
One member of the PSC is designated as the Chair and is the ultimate adjudicator in case of deadlock or irretrievable break down of decision-making, or in case of disputes over voting.
When is a PSC vote required ?
A vote of the PSC is required in the following cases:
- Requests for changes
- Addition or removal of PSC members (including the selection of a new Chair)
- Release process
In addition, a vote can be summoned for:
- Changing PSC rules and processes
- Anything else that might be controversial
Requests for changes
A Request for Changes describes a change in iota2 code, API, infrastructure or processes that need to be submitted to the PSC vote:
- Anything that could cause backward compatibility issues,
- Adding substantial amounts of new code,
- Changing inter-subsystem APIs, or objects.
It should describe :
- What changes will be made and why they will make a better iota2,
- When will those changes be available (target release or date),
- Who will be developing the proposed changes.
Those elements should be provided in an email to the developer list, with subject starting by "Request For Changes: ". If the proposers are not able to develop the changes by themselves, they should inquire the developer forum to see if someone can. No Request For Changes will be submitted to vote without evidence of appropriate means of achievement.
Add or remove PSC members
To be eligible for membership in the PSC, a person should demonstrate a substantial and ongoing involvement in iota2. The PSC is not only composed of iota2 developers as there are many ways to join and contribute to the project. Anyone is eligible to be nominated to the iota2 PSC. Ideally, nominees would be iota2 users or developers who have a deep understanding of the project. In addition, nominees should meet the qualifications set forth in this document. Anyone can submit a nomination.
The release manager (the PSC member in charge of release planning) submits to vote the following release decisions:
- Date of the next release
- Codename of the next release
- Date and revision of Release Candidate
- Date and revision of Final Release
- Date and revision of bug-fixes Release
- Proposals are written up and submitted as an issue for discussion and voting, by any interested party, not just committee members. Proposals are available for review for at least three days before a vote can be closed. It is acknowledged that some more complex issues may require more time for discussion and deliberation.
- Respondents may vote "+1" to indicate support for the proposal and a willingness to support implementation.
- Respondents may vote "-1" to veto a proposal, but must provide argumented reasoning and alternate approaches to resolve the problem within the two days.
- A vote of -0 indicates mild disagreement, but has no effect. A 0 indicates no opinion. A +0 indicates mild support, but has no effect.
- Anyone may comment and vote on proposals on the list, but only members of the PSC's votes (including the Chair) will be counted ("eligible voters").
- A proposal will be accepted if it receives at least +2 (including the proponent) and no vetos (-1)
- If a proposal is vetoed, and it cannot be revised to satisfy all parties, then it can be resubmitted for an override vote in which a majority of all eligible voters indicating +1 is sufficient to pass it. Note that this is a majority of all committee members, not just those who actively vote.
- Upon completion of discussion and voting the proposers should announce whether they are proceeding (proposal accepted) or are withdrawing their proposal (vetoed).
- The Chair adjudicates in cases of disputes about voting.
Current members and roles
|CNES||Jordi Inglada||chair, infrastructure|
|CS-SI||Arthur Vincent||release/merge manager|
|INRA||Mathieu Fauvel||community manager|