Community - Samsung/cordova-plugin-toast GitHub Wiki

Community Guidelines

All community members must abide by rules of common sense, civility and good neighborliness. Frank discussion is welcomed and encouraged with the goal of arriving at the best technical solution possible. Discussion about the people participating in development is not welcomed and ad hominem attacks will not be tolerated. Community participants must adhere to these simple rules:

  • Respect and acknowledge all contributions, suggestions and comments from the community.
  • Listen and be open to all opinions, which are subject to open discussion.
  • Help each other and the other Modules.
  • Assume people mean well.
  • Keep Project communications friendly.

Community Consensus, Lazy Consensus, and Silent Consent

Community consensus about a Project issue means that the issue has been submitted to and discussed via a Project issue tracker system by Contributors, Reviewers, and Maintainers, and that ALL discussing member agree about the issue. Lazy consensus means that Contributors may proceed with work when they have reason to believe that other Contributors in the community will agree with the direction of their work, and do not need to stop or initiate unnecessary discussion about the work. Contributors should publish their work (that is, merge proposals to version control) in a timely manner to allow others to possibly raise issues about the work. When the Contributor is not sure there will be consensus, they should raise a proposal via a Project issue tracking system. In all communication via a Project issue tracking system, the principle of silent consent applies: any member who does not communicate a reasoned alternative in course of a discussion implicitly agrees with the communicated proposal. When consensus between members is reached in ways other than a Project issue tracking system (such as face-to-face discussions), this is NOT community consensus and any such proposal reached is considered to be an UNapproved proposal until submitted to a issue tracking system, thus providing the opportunity for dissenting opinions to be voiced and community consensus to be reached. When community consensus about a Project issue CANNOT be reached in a timely manner, the Steering Committee will make the decision on how to proceed.

Meritocracy

Responsibilities in the Project (including decision making) are given to those who exhibit both the technical skill and dedication to a Module via their ongoing valuable contributions. Decision making happens inside the community, with more weight given to those who are more familiar with the code.

Governance

In addition to developing under an open source license, this project uses an open source approach, which welcomes everyone to participate, contribute, and engage with each other throughout the progress of the Project.

Project Roles

This project and Modules recognizes the following formal roles: Contributor, Reviewer, and Maintainer. The following people are currently assigned Project roles (with their area of specialty):

Contributor

A Contributor is a developer who wishes to contribute to the Project at any level. Contributors who show dedication and skill are rewarded with additional rights and responsibilities. Their opinions weigh more when decisions are made, in a fully meritocratic fashion. Contributors have the following rights and responsibilities:

  • Right to contribute code, documentation, translations, artwork, etc.
  • Right to report defects (bugs) and suggestions for enhancement.
  • Right to participate in the process of reviewing contributions by others.
  • Right to initiate and participate in discussions in the Project issue tracking system.
  • Right to approach any member of the community with matters they believe to be important.
  • Right to provide new, relevant information to reopen decisions.
  • Responsibility to abide by decisions that have been made.
  • Responsibility for issues and bugs introduced by one's own contributions.
  • Responsibility to respect the Community Guidelines.
  • Responsibility to provide constructive advice whenever participating in discussions and in the review of contributions.

Reviewer

A Reviewer is a Contributor who is also responsible for the maintenance of one or more particular areas of project source code or of Module(s). Reviewers have the following rights and responsibilities, in addition to those for Contributors:

  • Right to, in conjunction with the module Maintainer, set short-term and medium-term goals for their area of code or Modules.
  • Right to make more invasive changes to their areas of code or Modules, when required in exceptional cases.
  • Right to approve their own contributions, after discussing with other Contributors.
  • Right and responsibility to participate in new feature development.
  • Responsibility to ensure all contributions to the Module have been reviewed within a reasonable time.
  • Responsibility to ensure the quality of the code to expected levels.
  • Responsibility to monitor discussions in the Project issue tracking system.
  • Responsibility to participate in the Project quality verification and release processes, when they happen.

Maintainer

A Maintainer is a Contributor who is responsible for knowing, directing, and anticipating the needs of their assigned GearVRf source code module(s). Maintainers have the following rights and responsibilities, in addition to those for Contributors and Reviewers:

  • Right to set the overall organization of the source code in their Modules.
  • Right to participate in the decision making of their Modules.
  • Responsibility to participate in new feature development and to be a member of the Steering Committee.

Selection of Reviewers and Maintainers

Exactly one Maintainer is selected for each module. Therefore, a new Maintainer can be selected only for areas where there currently is no one in that position. A candidate for the Reviewer role should be one of the Contributors who has submitted at least 10 non-trivial patches for the Module and has shown characteristics consistent with the requirements of the Reviewer role. Any Contributor can nominate a community member for the role of Reviewer or Maintainer, by providing proper evidence. Members can nominate themselves. The selection process should be achieved by consensus of all community members. If consensus cannot be achieved, the Steering Committee will make the decision. All decisions must be ratified by the Steering Committee.

Revocation of Reviewer / Maintainer Status

A Maintainer or a Reviewer who has intentionally abused his review privilege may have it temporarily suspended on the request of other Reviewers or Maintainers. Reviewers and Maintainers not including the person under consideration should discuss the revocation of the person. If consensus cannot be reached, the Steering Committee will make the decision. All decisions must be ratified by the Steering Committee.

Decision Making Process

Decisions about the Project are always made at the lowest level possible that is applicable for the decision in question. Decision makers always need to keep in mind the Community Guidelines, Project goals, and roadmap. Community members make decisions when participating in discussions via a Project issue tracking system, on bug or feature reports, and in reviewing commits. Their arguments about why a given decision should be made are part of the consensus that needs to be reached for the decision. At this level, the principle of meritocracy is important, as the opinion of those who have contributed more will be given more weight in consensus-building. In cases where Contributors cannot agree and reach consensus on a decision: Decisions affecting a single module will be made by the module's Reviewers and Maintainer. Decisions that affect more than one Module will made by the Reviewers and Maintainers of the affected Modules. If the empowered Contributors, Reviewers, and Maintainers cannot agree and reach consensus, the decision will be made by the Steering Committee following its own decision making process.

Steering Committee

The Steering Committee oversees and guides the progress of this open source project. The Steering Committee has the following responsibilities:

  • Responsibility to oversee the health of the Project community.
  • Responsibility to set the goals and roadmap for the Project .
  • Responsibility to oversee and facilitate the development of source code under the governance rules of the Project .
  • Responsibility to guide and direct progress towards Project goals.
  • Responsibility to execute and participate in the evaluation of competing open source implementations.

Modules

Following projects are regarded as a Module which is consisting this project. They are developed and maintained for the single project goal. They shares the governance rules and relevant process.