feat: charter

nativescript-charter.md

@@ -0,0 +1,125 @@
+# NativeScript Charter
+
+## Section 0. Guiding Principle
+
+NativeScript is part of the OpenJS Foundation. The project operates transparently, openly, collaboratively, and ethically. Project proposals, timelines, and status must not merely be open, but also easily visible to outsiders.
+
+## Section 1. Scope
+
+NativeScript provides platform APIs directly to the JavaScript runtime (with strong types) for a rich TypeScript development experience. As an open-source framework to develop apps for iOS, visionOS, Android, macOS and other platforms combining a best of all worlds approach marrying familiar Web approaches like CSS and view templating with common platform languages (Swift, Kotlin, Objective-C, Java) it delivers a liberating toolset for developers.
+
+It combines a node based CLI as an approachable interaction point for JavaScript developers to interact with native platform development spanning Xcode and Android Studio processes.
+
+### 1.1: In-scope
+
+Section Intentionally Left Blank
+
+### 1.2: Out-of-Scope
+
+Section Intentionally Left Blank
+
+## Section 2. Relationship with OpenJS Foundation CPC.
+
+Most large, complex open source communities have both a business and a technical governance model. Technical leadership for the projects within the OpenJS Foundation is delegated to the projects through their project charters by the OpenJS Cross Project Council (CPC). In the case of NativeScript, it is delegated to the NativeScript Technical Steering Committee ("TSC"). OpenJS Foundation's business leadership is the Board of Directors (the "Board").
+
+This charter can only be amended with the approval of the CPC.
+
+## Section 3. Establishment of the TSC
+
+TSC members can be either _regular_ members or _voting_ members. Regular members can attend meetings and participate in TSC discussions, but do not vote. Voting members can do everything regular members can do, and also have the ability to cast votes when consensus is not reached on an issue.
+
+TSC memberships are not time-limited. There is no maximum size of the TSC. The TSC must have at least four voting members.
+
+The TSC may add additional voting members to the TSC through meeting consensus. The consensus requires at least five TSC members to be present to approve a new voting member.  A TSC member can be removed from the TSC by voluntary resignation or by consensus with at least five voting members to be present. A vote in a TSC meeting can be used to change a regular TSC member to a voting TSC member, or to change a voting TSC member to a regular TSC member.
+
+No more than one-half of the TSC voting members may be affiliated with the same employer. If a change in TSC voting membership or a change of employment by a TSC voting member creates a situation where more than one-half of the TSC voting membership shares an employer, then the situation must be immediately remedied by the removal of voting member status from one or more TSC voting members affiliated with the over-represented employer(s).
+
+The TSC shall meet regularly using tools that enable participation by the community (e.g. weekly on a Zoom meeting, or through any other appropriate means selected by the TSC). The meeting shall be directed by the TSC Chairperson. Responsibility for directing individual meetings may be delegated by the TSC Chairperson to any other TSC voting member. Minutes or an appropriate recording shall be taken and made available to the community through accessible public postings.
+
+TSC voting members are expected to regularly participate in TSC meetings and issue triaging.
+
+A TSC voting member is automatically converted to a TSC regular member if they do not participate in three consecutive TSC votes.
+
+## Section 4. Roles & Responsibilities of the TSC
+
+Subject to such policies as may be set by the CPC, the TSC voting members are responsible for all technical development with NativeScript, including:
+
+* Setting release dates.
+* Release quality standards.
+* Technical direction.
+* Project governance and process.
+* GitHub repository management.
+* Conduct and maintain guidelines defined by the OpenJS Foundation Cross Project Council.
+* Maintaining the list of additional collaborators.
+* Development process and any coding standards.
+* Mediating technical conflicts between collaborators or `NativeScript` projects.
+
+The TSC voting members will define NativeScript project's release vehicles.
+
+### Section 4.1. NativeScript Project Operations
+
+The TSC voting members will establish and maintain a development process for NativeScript. The development
+process will establish guidelines for how the developers and community will operate. It will, for example, establish appropriate timelines for TSC review (e.g. agenda items must be published at least a certain number of hours in advance of a TSC meeting).
+
+Note that project operations remain subject to any relevant policy or process specified by the OpenJS Foundation board or Cross Project Council.
+
+### Section 4.2. Decision-making, Voting, and/or Elections
+
+#### Section 4.2.1. Elections
+
+Leadership roles in NativeScript will be peer elected representatives of the community.
+
+For election of persons (such as the Chair), a multiple-candidate method should be used, such as:
+
+- [Condorcet](http://en.wikipedia.org/wiki/Condorcet_method) or
+- [Single Transferable Vote](http://en.wikipedia.org/wiki/Single_transferable_vote)
+
+Multiple-candidate methods may be reduced to simple election by plurality when there are only two candidates for one position to be filled. No election is required if there is only one candidate and no objections to the candidates election. Elections shall be done within NativeScript by the Collaborators active in the Project.
+
+NativeScript will elect from amongst Regular and Voting members of NativeScript:
+
+- a Chair and a Vice Chair to work on building an agenda for NativeScript meetings
+- NativeScript Directors to represent the project and related communities to the CPC Board
+
+The term for each of these roles is one year (as defined in the [OpenJS Foundation bylaws](https://bylaws.openjsf.org/)).
+
+NativeScript shall hold annual elections to select a Chair, Vice Chair, and Directors. NativeScript can choose to hold those elections at different times of the year or concurrently.
+
+There are no limits on the number of terms a Chair, Vice Chair, or Director may serve.
+
+The Chair and Vice Chair may be (but are not required to be) Directors.
+
+#### Section 4.2.2. Decision Making
+
+The CPC follows a Lazy Consensus Seeking decision-making model inspired by the [Apache Software Foundation's model](https://community.apache.org/committers/decisionMaking.html#lazy-consensus).
+
+Lazy consensus is achieved by making a proposal in a forum that will reach all members of the group who should have the opportunity to participate in reaching consensus and waiting for an appropriate amount of time given the nature of the decision for anyone to object. It is not necessary to get explicit approval to proceed from all members, silence indicates consent. However, objections must be resolved in order to achieve consensus.
+
+#### Section 4.2.3. Voting
+
+Voting should only be done as a last resort.
+
+If a proposal cannot reach consensus after a reasonable period of discussion, a voting member can call for objections to be overruled through an asynchronous vote. If this call is seconded by another voting member, an asynchronous vote must be organized. For the objections to be overruled, at least 2/3 of all voting members must vote in favor of overruling the objections.
+
+This voting process is designed to make it difficult to move a proposal forward without consensus, but prevent someone from blocking progress through objections.
+
+## Section 5. Definitions
+
+**Project**: a technical collaboration effort, e.g. a subsystem, that is organized through the NativeScript organization creation.
+
+**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 Project's Governing Body.
+Contributors should rarely be encumbered by the Chair or Directors.
+
+**Collaborator**: a Contributor within a Project that has made significant and valuable contributions and has been given commit-access to that Project repository.
+
+**Governing Body**: a group of Collaborators within a Project elected to represent the Project in an official decision making role as defined in the Project's governance policies.
+
+## Section 6. Changes to this Document
+
+Changes to this document require CPC consensus and approval from the OpenJS Foundation Board.
+
+----
+
+This work is a derivative of the [Node.js Project TSC Charter](https://github.com/nodejs/node/blob/main/TSC_CHARTER.md).