feat: charter

nativescript-charter.md

@@ -0,0 +1,105 @@
+# 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 brings native platform APIs directly into the JavaScript runtime, enriched with robust TypeScript typings, ensuring a seamless and powerful development experience. As an open-source framework for building applications across iOS, visionOS, Android, macOS, and more, it uniquely blends familiar web development paradigms—such as CSS styling and template-driven views—with popular native languages including Swift, Kotlin, Objective-C, and Java. This integration offers developers unparalleled flexibility and ease.
+Its intuitive CLI further simplifies interaction with native platform development processes, making native development approachable for JavaScript developers.
+
+### 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 memberships are not time-limited. There is no maximum size of the TSC.
+
+The TSC may add additional members to the TSC through meeting consensus. The consensus requires at least five TSC members to be present to approve a new member.  A TSC member can be removed from the TSC by voluntary resignation or by consensus with at least five members present.
+
+No more than two-thirds of the TSC members may be affiliated with the same employer. If a change in TSC membership or a change of employment by a TSC member creates a situation where more than two-thirds of the TSC membership shares an employer, then the situation must be immediately remedied by the removal of a member 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 member. Minutes or an appropriate recording shall be taken and made available to the community through accessible public postings.
+
+TSC members are expected to regularly participate in TSC meetings and issue triaging.
+
+A TSC member is automatically removed if they do not participate in at least 2 annual meetings.
+
+## Section 4. Roles & Responsibilities of the TSC
+
+Subject to such policies as may be set by the CPC, the TSC 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 members will define NativeScript project's release vehicles.
+
+### Section 4.1. NativeScript Project Operations
+
+The TSC 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
+
+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 members of the TSC.
+
+NativeScript will elect from members of NativeScript:
+
+- a Chair and a Vice Chair to work on building an agenda for NativeScript meetings
+
+NativeScript shall hold annual elections to select a Chair and Vice Chair. 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 and Vice Chair may serve.
+
+#### Section 4.2.2. Decision Making
+
+The TSC 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 member can call for objections to be overruled through an asynchronous vote. If this call is seconded by another member, an asynchronous vote must be organized. For the objections to be overruled, at least 2/3 of all 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.
+
+TSC members are all _voting_ members.
+
+## Section 5. Changes to this Document
+
+Changes to this document require CPC approval.
+
+----
+
+This work is a derivative of the [Node.js Project TSC Charter](https://github.com/nodejs/node/blob/main/TSC_CHARTER.md).