diff --git a/README.md b/README.md index 3f58260..f613491 100644 --- a/README.md +++ b/README.md @@ -1,159 +1,192 @@ -Governance Draft (as of September 2023) +Governance Proposal ( 2024 ) ---- ## Preamble + iTowns is an **open-source framework** designed for the **efficient visualization, navigation, and interaction** with **multi-scale 2D and 3D geospatial data** on the **web**. Built on the [`three.js`](three) general-purpose 3D library, it enables users to easily build their own customized 3D geographic applications. iTowns is a **geographic commons**, developed collectively by a diverse community of contributors, comprising independent developers, public organizations, research laboratories and private companies. The commons is guided by **rules** that safeguard its expansion and the immutability of its open and shared nature. -This document formalizes the **core values**, **community structure** and **governance** of the [`iTowns`](itowns) project. - -## Definitions -- A "**User**" encompasses individual or organization using the `iTowns` framework. -- A "**Contributor**" refers to any individual or organization actively involved in improvements to the iTowns project, whether through feature, documentation additions or bug fixes. -- A "**Core developer**" is any contributor holding commit rights to the main branch of the project. -- A "**Stakeholder**" refers to organizations providing financial support for the growth, initiatives, and activities of the iTowns project. - These stakeholders are responsible for all governance, funding, and institutional decisions. -- The "**Community**" serves as an umbrella term, encompassing users, contributors, and stakeholders within the iTowns project. +This document formalizes the **core values**, **community structure** and **governance** of the [`iTowns`](itowns) project. ## Values -- iTowns is a **commons**, developed collectively by a diverse community. - Its **open and shared nature** is **immutable**. -- Operating as **free software** under the MIT or CeCILL-B license, it permits unrestricted reuse and modifications, with the source code readily accessible at [https://github.com/iTowns/itowns](itowns:github). -- Contributors must adhere to the established rules and agree to the [**code of conduct**](coc). -- **Peer reviewing** is a fundamental aspect of the project. - Contributors can gain a more significant role by providing high-quality - contributions within the established guidelines. -- The community holds **sovereignty** and autonomously exercises governance over the project, free from external authority. -- A **public roadmap** displays forthcoming developments. + +- iTowns is a **commons**, developed collectively by a diverse community. Its **open and shared nature** is **immutable** +- Operating as **free software** under the MIT or CeCILL-B license, it permits unrestricted reuse and modifications, with the source code readily accessible at [https://github.com/iTowns/itowns](itowns:github) +- Contributors must adhere to the established rules and agree to the [**code of conduct**](coc) +- **Peer reviewing** is a fundamental aspect of the project. Contributors can gain a more significant role by providing high-quality contributions within the established guidelines +- The community holds **sovereignty** and autonomously exercises governance over the project, free from external authority +- **Future developments** are publicized and discussed openly before implementation - The dynamics of the open-source project are maintained to keep it aligned with **state of the art developments** in the field of 3D geospatial data visualization. +## Roles + +- A "**User**" encompasses an individual or organization using the `iTowns` framework. +- A "**Contributor**" refers to any individual or organization actively involved in improvements to the iTowns project, whether through feature development, documentation additions, bug fixes or other contributions to the project. +- A "**Core contributor**" is any contributor holding commit rights to the main branch of the project. These core developers handle technical governance of the project and guarantee its durability and independance +- A "**Sponsor**" refers to organizations providing financial support for the growth, initiatives, and activities of the iTowns project. These sponsors are responsible for funding decisions, and governance of the sponsors committee +- The "**Community**" serves as an umbrella term, encompassing users, contributors, sponsors and stakeholders within the iTowns project. ## Sustainability -- The project identifies **key stakeholders** who contribute significantly to its sustainability across its life cycle, adhering to the governance rules defined in this document. - Current **key stakeholders** are given in the [membership](./membership.md) document. +- The project identifies **key sponsors** which contribute significantly to its sustainability across its life cycle, adhering to the sponsors governance rules defined by the project. Current **key sponsors** are given in the [members](./members.md) document. + +## Core contributors + +A "**Core contributor**" is any contributor holding commit rights to the main branch of the project. These core contributors handle technical governance of the project and guarantee its durability and independance. + +### Operation of Core Contributors + +- Ensure the project's sustainability in terms of maintainability and technical debt +- **Monitor** ongoing **developments** +- Make consensus-based decisions on technical architecture and ensure its coherence +- Operate continuously, with responsiveness, in a dedicated public discussion channel +- Enforce the principle of reviewing and cross-validation, prohibiting validators from validating their own contributions or those of their respective organizations +- **Address requests** in issues + +#### Joining the Core Contributors + +Every contributor holding commit rights to the main project is a Core Contributor. + +Achieving status of Core Contributor requires significant contributions to the project, a demonstrated ability to produce high-quality code or other resources, and adherence to the guidelines outlined in the code of conduct, CODING.md and CONTRIBUTING.md documents. + +Access to the Core Contributor role is subject to a double majority vote by the Core Contributors. This role is granted on an individual basis (not as part of an organization). It may be rescinded for rule violations or if contributions cease for a one-year period. Revocation requires a double majority vote, excluding the concerned individual. + +A Core Committer loses their rights after more than 6 months of inactivity and may also have their membership status challenged by peers for non-compliance with governance and project rules (code of conduct, adherence to contribution rules, etc.). + +## Governance Organization & committees -## Governance Organization Governance is structured into quickly deployable **committees**, each possessing **well-defined responsibilities** and a **transparent decision-making process**. The objective is to ensure clarity and understanding for the `iTowns` project community. ### Project Steering Committee (PSC) -Comprising stakeholders providing financial support the growth, initiatives and activities of the iTowns project, the **Project Steering Committee** (*PSC*) **oversees the strategic direction** of the project. + +The project steering committee is the main governing body for the OpenSource project. The PSC comprises a subset of core developers holding commit rights to the main branch of the project. The PSC operates openly with a consensus based approach. The PSC mainly exists to solve conflicts or urgent issues where a consensus is hard to reach. The PSC may delegate specific responsibilities to particular project members. + +The PSC upholds adherence to the project's architectural coherence, technical viability, and oversee contributions in accordance to the roadmap. #### Role of the PSC -- Shapes the **strategic directions** of the project in collaboration with all stakeholders. -- **Arbitrates** significant technical-functional and scientific roadmap proposals submitted by the product committee. -- Handles **relationships with external entities** such as industrial partners, institutional bodies, scientific organizations and associations. -- Makes **decisions on budget and intellectual property** matters. -- Oversees and approves **project communication** strategies. -- **Establishes and executes a governance framework**, including amendment to the present document, requiring a two-thirds majority approval. + +- **Ensure that all projects rules are respected**, be it values, governance or technical processes +- **Arbitrates** on the conformity of pull requests with the functional roadmap and established technical consensuses +- **Oversees the project's sustainability** in terms of maintainability and technical debt +- **Arbitrates decisions on technical architecture** and ensures its coherence +- Oversees ongoing **developments** +- Arbitrates requests for Core Contributor's rights and their removal + +The PSC designates a release manager every two years with a majority vote. + +#### Meetings + +The PSC holds meetings at the request of any PSC member, and every 3 months minimum, and publishes meeting summaries via a public channel on GitHub. Active contributors who are not committee members may be invited to PSC meetings. + +Members opinions are documented for transparency and as an objective metric of active participation, and proposed and adopted solutions are specifically reported. + +### Sponsors committee + +Comprising sponsors providing financial support the growth, initiatives and activities of the iTowns project, the **Sponsors committee** (*SC*) manages funding and investment, as well as mutualization and sharing of development efforts. It oversees the synchronization of efforts among its members. It also helps on the communication and marketing levels. The sponsors committee has a specific power to veto certain developments. + +Through funding and resources allocation, the Sponsors Committee shapes the **strategic directions** of the project. + +#### Role of the Sponsors committee + +- Makes **decisions on budget** matters and funds allocation +- Shapes the **strategic directions** of the project in collaboration with all stakeholders +- **Prioritize** technical and functional proposal, through funding and resource allocation +- Handles **relationships with external entities** such as industrial partners, institutional bodies, scientific organizations and associations +- Oversees **project communication** strategies and actions +- **Establishes and executes its own governance** - **Votes membership** requests within the committee. +- Has the **right to veto** specific contributions, with an open written motivation referencing core project values, processes and documents -#### Joining the PSC -Organizations seeking PSC membership must meet the following prerequisites: +#### Joining the Sponsors committee -- **Contribute** an amount equivalent of a full-time annual commitment for one year to the project. +Organizations seeking SC membership must meet the following prerequisites: + +- **Contribute** an amount equivalent of a full-time annual commitment for one year to the project ( funding or resources ) - **Adhere** to project's governance rules -- **Commit to continue collaboration** under equivalent or higher resource -conditions for a minimum of two years. +- **Commit to continue collaboration** under equivalent or higher resource conditions for a minimum of two years. -**New memberships** are subject to a simple majority vote by current PSC members, taking into account adherence to the values and rules of the present document. +**New memberships** are subject to a simple majority vote by current Sponsors committee members, taking into account adherence to the values and rules of the present document. -Members requesting or discontinuing collaboration for a one-year period will automatically exit the PSC. +Members requesting or discontinuing collaboration for a one-year period will automatically exit the Sponsors committee. -#### PSC meetings -- Convenes **formal meetings every six months**, either in person or via video conference and remains accessible via email as required by the product or technical committees. -- Publishes **meeting summaries** on a dedicated public channel ([iTowns website](itowns) or [GitHub](itowns:github)). -- Collaborates closely with the product committee. -- Has the authority to **invite** other project actors to its meetings, granting them an advisory role without voting rights. +#### Meetings + +The Sponsors Committee : +- Convenes **formal meetings every six months**, either in person or via video conference, and remains accessible via email as required by the product committe or PSC +- Publishes **meeting summaries** on a dedicated public channel ([iTowns website](itowns) or [GitHub](itowns:github)) +- Collaborates closely with the product committee +- Has the authority to **invite** other project actors to its meetings, granting them an advisory role without voting rights ### Product Committee (PC) -The **Product Committee** (*PC*) comprises representatives from project-stakeholders and elected core developers. -The PC **oversees the functional aspects and roadmap** of the project, ensuring alignment with defined goals and needs. + +The **Product Committee** (*PC*) comprises representatives from project-stakeholders and core developers. + +The PC **oversees the functional aspects and roadmap** of the project, ensuring alignment with defined goals and needs, and serves as an operational relay of the Sponsors Committee. #### Role of the PC -- Ensures **project alignment** with the Community's needs and the strategic directions set by the PSC for the project. -- Organizes the collection of requirements based on information provided by the Strategic Committee, Scientific Committee and the Community. -- Coordinates the collection of user requirements through pull requests, user feedback, and discussions. -- Manages the project roadmap (following potential arbitration by the Strategic Committee). -- Validates developments before their deployment in a pre-production environment. -- Plans the version release schedule. + +- Ensures **project alignment** with the Community's needs and the strategic directions set by the Sponsors for the project +- Organizes the collection of requirements based on information provided by the Sponsors Committee and the Community +- Coordinates the collection of user requirements through pull requests, user feedback, and discussions +- Proposes roadmap items to the Sponsors Committee for funding and resource allocation +- Proposes release schedule of feature items to the Sponsors Committee with corresponding resources +- Help Core developers to evaluate and improve proposals +- Contributes to functional testing of pre-production versions #### Joining the PC -The annual renewal and structure of the Product Committee are as follows: -- Two-thirds of its members are designated by the PSC. + +The bi-annual renewal and structure of the Product Committee are as follows: + +- Two-thirds of its members are designated by the Sponsors Committee. - One-third is elected by the Core Developers. #### Meetings + - Convenes **formal meetings every two months** and engages in **continuous discussion** through a [dedicated public channel](itowns:chan). - Publishes **meeting summaries** on a dedicated public discussion channel ([iTowns website](itowns) or [Github](itowns:github)). - Has the authority to **invite** other project actors to its meetings, granting them an advisory role without voting rights. - -### Core Developers -The "**Core developers**" committee comprises contribution validators holding commit rights to the main branch of the project. -They uphold adherence to the project's architectural coherence, technical viability, and oversee contributions in accordance to the roadmap. - -#### Role of the Core Developpers -- **Ensures the project' sustainability** in terms of maintainability and technical debt. -- Makes **decisions on technical architecture** and ensures its coherence. -- **Monitors** ongoing **developments**. -- **Addresses requests** in issues. -- **Validates** the conformity of pull requests with the functional roadmap and - established technical consensuses. -- Arbitrates requests for Core Developers rights and their removal. - -#### Operation of the Core Developpers -- Operates continuously, with responsiveness deadlines, in a dedicated public discussion channel. -- Holds meetings every two months and publishes meeting summaries via a public channel on GitHub. Active contributors who are not committee members may be invited. -- Member opinions are documented for transparency and as an objective metric ofactive participation. -- Tracks proposed and adopted solutions. -- Enforces the principle of cross-validation, prohibiting validators from validating their own contributions or those of their respective organizations. - -#### Joining the Core Developpers -Every contributor holding commit rights to the main project is a Core Developer. -Achieving status of Core Developer requires significant contributions to the project, a demonstrated ability to produce high-quality code, and adhere to the guidelines outlined in the code of conduct, CODING.md and CONTRIBUTING.md documents. - -Access to the validator role is subject to a double majority vote by the Core Developers. -This role is granted on an individual basis (not as part of an organization). -It may be rescinded for rule violations or if contributions cease for a one-year period. -Revocation requires a double majority vote, excluding the concerned individual. - -A Core Committer loses their rights after more than 6 months of inactivity and may also have their membership status challenged by peers for non-compliance with governance and project rules (code of conduct, adherence to contribution rules, etc.). - - ## Contribution process -See [Proposal process](proposal.md). +See [Proposal process](proposal.md). ## Versions -A new version of iTowns is released every 2 months. -### Release -- The PC leads the release process with the Core Developpers and set a release date. +A new version of iTowns is released every 4 months. + +### Release + +- The release manager validates the next planned release date +- The release manager launches the release process - Tests are launched before the release of the new version: + Unit tests + Functional tests + Client application test on the next branch + Regression tests through a complete run of all examples. +- The release manager validates the release and finishes the release process + +The release manager may forward the release responsibility to another Core Contributor for a specific release. ### Communication -- The changelog is distributed on Github. + +- The Changelog is published on Github. - Distribution on npmjs/github: + Description of the version + Link to changelog - + Link to examples. + + Link to examples ### Roadmap Update -- The roadmap is public and updated on a two-month cycle. + +- The items foreseen for the next releases are published on a public (non-exhaustive) roadmap and updated regularly by the Product Committee and the Sponsors Committee - the project's progress is public and can be tracked at https://github.com/iTowns/itowns/projects?query=is%3Aopen. -- Anyone can suggest adding a new feature to the roadmap through an proposal. +- Anyone can suggest adding a new feature to the roadmap through a proposal. [coc]: https://www.contributor-covenant.org/fr/version/2/0/code_of_conduct/ [itowns]: http://www.itowns-project.org/ diff --git a/membership.md b/membership.md index 3f6d30d..b094217 100644 --- a/membership.md +++ b/membership.md @@ -1,26 +1,41 @@ -This document enumerates the current stakeholders and members of the different commitees of the iTowns project. +This document enumerates the current Sponsors and members of the different committees of the iTowns project. + +## Sponsors -## Stakeholders - [IGN](https://www.ign.fr/) - [Ciril Group](https://www.cirilgroup.com/) -## Commitees members -### Project Steering Committee (PSC) -The current designated members by the stakeholders are: +## Committees members + +### Sponsors Committee + +The current members of the sponsors committee are: + - DAVID Thomas (IGN) - GRIVEL Amaël (Ciril Group) - MELLIER Guillaume (IGN) - PEUZIN Thierry (Ciril Group) ### Product Commitee (PC) -The current designated members by the PSC are: + +The current members of the PC are : - LAVENANT Antoine (IGN) - PICAVET Loïc (Ciril Group) -The elected members by the Core Developers are: -- JAILLOT Vincent / BOUILLAGUET Quentin (co-chair) +- JAILLOT Vincent +- BOUILLAGUET Quentin + +### Project Steering Committee (PSC) + +Current members of the PSC are : + +- BOUILLAGUET Quentin +- JAILLOT Vincent +- GERMERIE-GUIZOUARN Madec + +## Core Contributors + +The current Core Contributors are : -### Core Developpers (CD) -The current elected members by the CD are: - BOUILLAGUET Quentin - CHOQUEUX Gérald - GERMERIE-GUIZOUARN Madec diff --git a/proposal.md b/proposal.md index ce841c0..f16239c 100644 --- a/proposal.md +++ b/proposal.md @@ -1,85 +1,84 @@ # Contribution and Review Process ## Introduction -Before making any contributions, it is important for contributors and the -community at large to open discussions (proposals) about addition or improvement -of features. -Those proposals are centralized on issues tagged "proposals" in the -`iTowns/itowns` repository. -This allows contributors to demonstrate the existence of real use cases and gain -a concrete understanding of user needs. - -The diagram below outlines this proposal process. - -## Type of Contribution -Contributions can be of three types: + +Before making any contributions, it is important for contributors and the community at large to open discussions ( proposals ) about addition or significant improvement of features. + +Those proposals are centralized on issues tagged "proposals" in the `iTowns/itowns` repository. + +This allows contributors to demonstrate the existence of real use cases and gain a concrete understanding of user needs, as well as a more fluid process for contributions, and better visibility for the end users and stakeholders. + +## Types of Contribution + +Contributions can be of 4 types: + +- **Documentation** - **Bug fixes** linked to an open bug issue on the `itowns/itowns` repository. -- **Documentation.** -- **Improvement of an existing feature or component** +- **Significant improvement of an existing feature or component** - **Addition of a new feature.** -*Note: Proposals are only required for improvements or additions of features. -Bug reports are sufficient for proposing a fix.* +*Note: Proposals are only required for improvements or additions of features. Bug reports are sufficient for proposing a fix.* ## Documentation -Documentation changes can be proposed directly through pull requests. In case of -questions or issues with documentation, an issue should be opened, following the -same proposal process as other contribution types. + +Documentation changes can be proposed directly through pull requests. In case of questions or issues with documentation, an issue should be opened, following the same proposal process as other contribution types. ## Bug Discovery and Correction Process -The entire bug discovery and correction process takes place on the itowns/itowns -repository. -1. A user or contributor submits a bug report through an issue (following the - defined template). -2. A contributor submits a fix by opening a pull request linked to the - corresponding issue in the description. -## Proposal Process -Improvements or new features occur through the opening of a dedicated proposal -on the itowns/itowns repository. +The entire bug discovery and correction process takes place on the `itowns/itowns` repository + +1. A user or contributor submits a bug report through an issue (using the predefined template) +2. A contributor submits a fix by opening a pull request linked to the corresponding issue in the description + +## Significant improvements and new features + +Significant improvements or new features occur through opening of a dedicated proposal issue on the `itowns/itowns` repository. This can be initiated in two ways: -- As a community member through an informal discussion. The final feature takes - shape through discussions and users feedback. -- As a contributor through an issue following the defined template: - - Concise details of the feature, including use cases and supported by user - needs. - - Technical explanation of the suggested implementation. - -*Note: Contributors can still directly open a pull request on the itowns/itowns -repository. However, it will be less prioritized (TODO: veto) than if it had -gone through the proposal process.* - -The Product Committee then validates the proposal through a vote (functional -consensus). -- If validated, the feature or improvement is added to the project's roadmap. -- If on hold (lack of maturity, interesting but longer-term), the issue remains - open, and discussions can continue. -- Otherwise, the issue is closed. - -*Note: After CP validation of a proposal from a discussion, one or more -contributors can take on its development. The contributor(s) opens an issue -following the defined template without detailing the feature (a link to the -discussion is sufficient) and without CP validation of this issue.* - -In this issue, technical consensus must be reached by a double majority of -reviewers (within a specified time, no response equals a yes). They evaluate: -- The technical quality of the chosen solution. -- The impact on the rest of the codebase. - -After functional and technical consensus, the contributor can: -- Implement the feature following the chosen solution. -- Open a draft pull request on the main itowns/itowns repository (linking to the - issue in itowns/itowns-proposals). -After implementation (when the pull request is ready), a two-step review phase -is conducted by two reviewers: -1. Functional review: The reviewer ensures that the implementation only adds the - proposed functionality. -2. Technical review: The reviewer ensures that the implementation meets - technical consensus. - -This review phase is simplified as previous discussions help understand the -author's intentions and choices. - -*Note: The reviewer is responsible for the implementation they validate and for -any bugs resulting from this validation.* +- As a community member through an informal discussion. The final feature takes shape through discussions and users feedback. +- As a contributor through an issue using the defined template containing: + - Concise details of the feature, including its rationale, and use cases supported by user needs + - Technical explanation of the suggested implementation + +*Note: Contributors can still directly open a pull request on the itowns/itowns repository. In this case, it is expected for the pull request to include the same informations as for a proposal issue. PRs submitted without proposal will not likely be prioritized by reviewers.* + +The Core Contributors are in charge of verifying the validity of the proposal : + +- adherence to processes, values and overall project direction +- technical coherency with existing code base +- technical quality of the chosen solution. +- impact on the rest of the codebase. +- non-regression + +Expressions of non-validity of the proposal must be motivated and their rationale explained, with reference to the values, processes and documents of the project. + +If at least one of the Core Contributors expresses a non-favorable advice to the proposal, the issue can remain open, the proposal can be amended and discussions can continue until the negative advice is removed. Meanwhile, no implementation corresponding to this proposal should be merged. + +The Product Committee can give advice on proposals, considering existing priorities, resource allocations and knowledge of other features currently planned. The PC can integrate the proposal to its roadmap items, and to the list of items subjects for resource allocations from the Sponsors. + +If a consensus is reached, or no negative advice from Core Contributor has been expressed 1 month after the last comment on the proposal, it is considered as acceptable, and a pre-approval of the corresponding Pull Request. + +## Implementation & review + +After the proposal phase, contributors can: +- Implement the feature following the chosen solution +- Open a draft pull request on the main itowns/itowns repository (linking to the proposal issue in `itowns/itowns`) + +After implementation, the PR is marked as "Ready", and the review phase can begin : + +1. Functional review: The reviewer ensures that the implementation adds the proposed functionality corresponding to the initial proposal +2. Technical review: The reviewer ensures that the implementation respects the project's processes and meets technical consensus + +The review can be made by any contributor. + +Product committee members are also expected to assess the functional aspect of the implementation. + +The merge action is achieved by a Core Contributor, who is expected to take responsibility for the code merged, with the collaboration of the initial contributor(s). + +This review phase is simplified as previous discussions around the proposal helped understand the author's intentions and choices. + +## Sponsors Comittee veto + +**At any point in time, the Sponsors Committee can emit a veto for a proposal or a Pull Request**. This veto must be motivated and its rationale explained in detail, with references to the project's values, processes and global strategy and purpose. + +