Skip to main content
Samsung Developer Program


GearVRf Project community guidelines, governance, and mailing lists

You can get help from, stay in touch with, and help other GearVRf aficionados.


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 in the GearVRf Project mailing Lists.


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 mailing list 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 mailing list.

In all communication via a Project mailing list, 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 mailing list (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 mailing list, 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.



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.




In addition to developing under an open source license, the GearVRf 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

The GearVRf Project recognizes the following formal roles: Contributor, Reviewer, and Maintainer.

The following people are currently assigned Project roles (with their area of specialty):


  • Maintainers
    • Tom Flynn (core)
    • Insu Song (extensions)


  • Reviewers
    • Mihail Marinov
    • Nola Donato
    • Roshan Chaudhari
    • Dmitriy Vasilev



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 mailing lists.
  • 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 is a Contributor who is also responsible for the maintenance of one or more particular areas of GearVRf 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 module.
  • 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 mailing lists.
  • Responsibility to participate in the Project quality verification and release processes, when they happen.



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 GearVRf 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, GearVRf Project goals, and GearVRf roadmap.

Community members make decisions when participating in discussions via a Project mailing list, 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 the open source GearVRf Project.

The Steering Committee has the following responsibilities:

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



module is a unit of GearVRf source code that accomplishes a specific objective; a module is a subsystem of GearVRf. Modules are established by the development community on an as-needed basis. Modules are hosted on the GearVRf Project infrastructure.

The development of each Module is led by one or more Reviewers and one Maintainer assigned to the Module, following the Community Guidelines and development community guidelines. New Modules can be suggested by any member of the community, but the final decision on establishing and hosting Modules rests with the Steering Committee. Modules that are no longer active are archived and do not have assigned Reviewers and Maintainers.


GearVRf Mailing Lists

You can contact GearVRf Project community members via the GearVRf Project mailing lists to get Project announcements, and discuss Project issues (such as asking questions, making suggestions, providing comments) :


GearVRf Project Mailing List Home Page ( Access any of the GearVRf Project mailing lists.
     Announcements Mailing List ( Get announcements related to the GearVRf Project.
     Developers Mailing List ( Discuss GearVRf development issues.
     General Mailing List ( Discuss general GearVRf Project issues.
     Testing Mailing List ( Discuss GearVRf testing issues.


  • Was this article helpful?