chore: update charter docs

CHARTER.md

@@ -0,0 +1,57 @@
+# kepler.gl Charter
+
+## Section 0: Guiding Principles
+
+kepler.gl believes that powerful geospatial analysis should be accessible to everyone, regardless of their technical background. We are committed to building a data-agnostic, high-performance, open-source tool that makes the visual exploration of large-scale location data intuitive, beautiful, and collaborative. We value openness, interoperability, and a welcoming community that grows through the shared contributions of its members.
+
+## Section 1: Mission and Scope of the Project
+
+kepler.gl is a data-agnostic, high-performance web-based application for visual exploration of large-scale geolocation data sets. Built on top of [deck.gl](https://deck.gl/) and [MapLibre GL](https://maplibre.org/), it is also a React component that uses [Redux](https://redux.js.org/) to manage its state and data flow. kepler.gl enables analysts, engineers, and researchers to quickly render millions of points, aggregate and filter data interactively, and share their findings without writing code.
+
+### 1.1: In-scope
+
+Section Intentionally Left Blank
+
+### 1.2: Out-of-Scope
+
+Section Intentionally Left Blank
+
+## Section 2: Relationship with OpenJS Foundation CPC
+
+The OpenJS Cross Project Council (CPC) delegates technical leadership of this project to the governing body defined in [Section 3 of this charter](#section-3-governing-body-of-the-project).
+
+This project is entitled to representation in the CPC through voting members as described in [Section 4](https://github.com/openjs-foundation/cross-project-council/blob/main/CPC-CHARTER.md#voting-members) of the CPC Charter.
+
+### 2.1 Other Formal Project Relationships
+
+Section Intentionally Left Blank
+
+## Section 3: Governing Body of the Project
+
+kepler.gl is governed by its [Technical Steering Committee (TSC)](./README.md).
+
+Governing body membership and governance of this project are defined in [GOVERNANCE.md](./GOVERNANCE.md).
+
+## Section 4: Responsibilities of the Governing Body of the Project
+
+The responsibilities of this project's governing body are described in [Section 6](https://github.com/openjs-foundation/cross-project-council/blob/main/CPC-CHARTER.md#section-6-non-responsibilities-of-the-cpc) of the CPC Charter.
+
+### Section 4.1 Project Operations & Management
+
+Section Intentionally Left Blank
+
+### Section 4.2: Decision-making, Voting, and/or Elections
+
+Decision making and voting follow the practices adopted by the CPC and described in [Section 9](https://github.com/openjs-foundation/cross-project-council/blob/main/CPC-CHARTER.md#section-9-decision-making) and [Section 10](https://github.com/openjs-foundation/cross-project-council/blob/main/CPC-CHARTER.md#section-10-voting) of the CPC Charter respectively.
+
+### Section 4.3: Other Project Roles
+
+Section Intentionally Left Blank
+
+## Section 5: Definitions
+
+Section Intentionally Left Blank
+
+## Section 6: Changes to this Document
+
+Changes to this document require [approval from the CPC](https://github.com/openjs-foundation/cross-project-council/blob/main/governance/GOVERNANCE.md#approving-project-charters).

CONTRIBUTING.md

@@ -0,0 +1,27 @@
+# Contributing to kepler.gl
+
+**Thanks for taking the time to contribute!**
+
+PRs and bug reports are welcome, and we are actively looking for new maintainers.
+
+[kepler.gl](https://kepler.gl) is a data-agnostic, high-performance web-based application for visual exploration of large-scale geolocation data sets. It is built on top of [MapLibre GL](https://maplibre.org/) and [deck.gl](https://deck.gl/), and is also a React component that uses [Redux](https://redux.js.org/) to manage its state and data flow.
+
+For details of how to set up the development environment, running tests, troubleshooting, and contributing to kepler.gl, see the [kepler.gl documentation](https://github.com/keplergl/kepler.gl/blob/master/README.md).
+
+## Community Governance
+
+kepler.gl is part of the [OpenJS Foundation](https://openjsf.org/). See the organization's [Technical Charter](./CHARTER.md) and [Community Governance Guidelines](./GOVERNANCE.md).
+
+### Technical Steering Committee
+
+kepler.gl development is governed by the kepler.gl [Technical Steering Committee (TSC)](./README.md).
+
+Maintainers of kepler.gl have commit access to the GitHub repository, and take part in the decision making process.
+
+If you are interested in becoming a maintainer, read the [governance guidelines](./GOVERNANCE.md).
+
+The [OpenJS Slack](https://slack-invite.openjsf.org/) can be utilized to reach out to the TSC.
+
+## Code of Conduct
+
+Please be mindful of and adhere to the OpenJS Foundation's [Code of Conduct](https://github.com/openjs-foundation/cross-project-council/blob/main/CODE_OF_CONDUCT.md) when contributing to kepler.gl.

GOVERNANCE.md

@@ -0,0 +1,119 @@
+# kepler.gl Community Governance Guidelines
+
+## Overview
+
+There are three types of roles in the community that maintains this project:
+
+- *Steering committee member*: A core maintainer of the project, provides leadership and oversees feature and technical directions.
+- *Maintainer*: A core developer of the project, oversees one or more feature areas, and shares the responsibility of release. Also referred to as a "feature owner."
+- *Contributor*: A casual participant on GitHub, including reporting bugs; answering questions; developing a third-party module that extends the capabilities of ours; creating public examples; submitting a PR for documentation enhancement or minor bug fix. Always welcome.
+
+The list of current steering committee members are documented in the kepler.gl TSC repo's [README](./README.md). Maintainers are documented in each repo's contributing guide (e.g. [`/CONTRIBUTING.md`](./CONTRIBUTING.md)).
+
+The [TSC Charter](./CHARTER.md) governs the operations of the TSC. All changes to the Charter need approval by the OpenJS Foundation Cross-Project Council (CPC).
+
+## The Steering Committee
+
+### 1a. A steering committee member’s privileges
+
+All of a maintainer's privileges (2a), and the following:
+
+- Voting right on the admittance/removal of steering committee members and maintainers
+- Administrator to the project's repo, and owner to the NPM organization
+- Approving external communications
+- Final veto power in roadmap planning
+
+### 1b. A steering committee member’s responsibilities
+
+- Manage project members and privileges according to the governance guidelines;
+- Ensure that the dev tools of the repo work consistently and as expected;
+- Organize and moderate community discussions, enforce the code of conduct;
+- Ensure that the dev process is followed by all contributors;
+- Ensure the consistency and quality of the documentation;
+- Manage blog posts, material for conference and meetup talks, and other brand presence in accordance with the OpenJS Project Marketing Guidelines.
+
+### 1c. Becoming a steering committee member
+
+A steering committee member should be
+
+- A long time maintainer to the project;
+- Recognized by the community for their depth of knowledge and community engagement;
+- Agrees to dedicate time to perform their committee duties.
+
+An existing maintainer can be nominated to join the steering committee by other steering committee members. The nomination is formally submitted as a PR to update the [TSC repo](./README.md). Nominations are approved by the steering committee.
+
+### 1d. Leaving the steering committee
+
+If a steering committee member can/will no longer perform their duties, they can be removed from the steering committee by the consensus of the rest of the steering committee members.
+
+## Maintainers
+
+### 2a. A maintainer's privileges
+
+- Roadmap planning
+  + Submit, approve and comment on RFCs.
+  + Participate in the planning meeting at the beginning of each release cycle (3a).
+  + Join the developer channel for the ongoing technical discussions, development activities and release updates.
+- Write permission to the repo, and membership to the NPM organization
+  + Merge commits, label/assign/close issues, cut release branches and publish new versions.
+  + Push to a branch in the main repo.
+  + Be added as a code reviewer by other contributors.
+- Represent kepler.gl publicly
+  + Promote kepler.gl at conferences and meetups.
+
+
+### 2b. A maintainer's responsibilities
+
+- Participate in the planning meetings and RFC reviews concerning the self-declared feature area(s);
+- Be responsive to bug reports, user questions, and code review requests in the self-declared feature area(s);
+- Comply with the projects’ [development process](./README.md).
+
+
+### 2c. Becoming a maintainer
+
+Any contributor to the project can self-nominate to become a maintainer if they:
+
+- Demonstrate familiarity with the project and expertise in the relevant domain (e.g. WebGL, deck.gl, Mapbox, React, etc.):
+  + Obtain the endorsement by an existing maintainer, or
+  + Have submitted at least one substantial PR (a complete feature or major bug fix) and remained active for more than 3 months in online discussions and relevant projects
+- Agree to the continuous maintenance of the self-declared feature area(s).
+
+The nomination is formally submitted as a PR to update the contributing guide (`/CONTRIBUTING.md`), with self-declared ownership of one or more feature areas. Nominations are approved by the steering committee.
+
+
+### 2d. Removal of the maintainer status
+
+A maintainer can be removed of their privileges if they:
+
+- Resigns; or
+- Repeatedly fails to perform their responsibilities (2b); or
+- Violates the project's code of conduct.
+
+The removal will be approved by the consensus of the steering committee.
+
+
+## Governance Practice
+
+The following process is followed by the steering committee and maintainers in addition to the existing [developer process](./README.md).
+
+### 3a. Roadmap planning
+
+Release roadmaps track high-level project directions that span multiple releases to implement and/or affect multiple feature areas. The steering committee meets once per release cycle to coordinate feature development and discuss the technical approaches. All maintainers are invited to this meeting to pitch ideas or comment on proposals.
+
+The project generally does not move forward with a proposal unless the meeting reaches consensus. Should there be unresolvable disagreement despite the best efforts, members of the steering committee have the final deciding power.
+
+Roadmaps are committed to the repo after the meeting and are the governing documents for development till the next planning meeting.
+
+### 3b. RFC
+
+Following the roadmap, an RFC must be submitted either as a PR or a GitHub issue before each feature/breaking change is implemented. It is expected to detail all proposed changes to the public API, outline the planned implementation, and evaluate the impact on existing use cases. Even with approval, an RFC should remain open for at least 5 business days to allow comments from all maintainers.
+
+
+### 3c. Code review
+
+A PR must request the code review from all feature owners whose codebase is directly and indirectly affected. The PR may merge if approved by all reviewers, or at least one approval along with “lazy consensus” (automatically obtained if 5 business days have passed since submission, unless someone objects).
+
+
+### 3d. Coordination
+
+Dedicated Slack channels will be established for the project's maintainers. Slack communication is encouraged for casual coordination and the sharing of business-sensitive information.

README.md

@@ -1,5 +1,11 @@
-# kepler.gl TSC
+This repo contains the organization charter, community guideline and developer process for all kepler.gl projects.
 
 
+## Technical Steering Committee
 
-This group is operating as part of the Urban Computing Foundation, under its [charter](https://github.com/ucfoundation/charter) and [code of conduct](https://github.com/ucfoundation/tac/blob/master/CODE_OF_CONDUCT.md).
+The section tracks the current governing body of the community. For their responsibilities and the decision-making process, see [Technical Charter](/CHARTER.md) and [Community Governance Guidelines](/GOVERNANCE.md).
+
+- [Shan He](https://github.com/heshan0131)
+- [Igor Dykhta](https://github.com/igorDykhta)
+- [Ilya Boyandin](https://github.com/ilyabo)
+- [Xun Li](https://github.com/lixun910)