Skip to content

Latest commit

 

History

History
102 lines (69 loc) · 8.63 KB

GOVERNANCE.md

File metadata and controls

102 lines (69 loc) · 8.63 KB
Raw

Samsung Inner Source Governance

The Samsung Inner Source Governance(the "Governance") sets forth the responsibilities and procedures for technical contribution to, and oversight of, the Samsung Inner Source Community(the "Community") within Samsung Electronics. Contributors to the Community MUST comply with the terms of the governance as well as any applicable policies of Samsung Electronics.

All the Communities under the Samsung Inner Source Program MUST inherit this Governance and each Community is allowed to create its own Community Rule but only as a type of ADDON tailoring. Additionally which SHOULD be announced each project wiki page with a title named 'Community Rules' and should be described in [Project List] page of your project in this portal.

1. Guideline for Operation

Samsung Inner Source Program uses an OPEN ENVIRONMENT which the CODE(Github enterprise version) as a source forge. The baseline of Inner Source Program repository is PUBLIC. If you have any specific reason to make it PRIVATE, you SHOULD make a request via Inner Source Portal. However the request COULD not be accepted if it doesn't have obvious reasons.

2. Roles and Responsibilities

The Samsung Inner Source Community Recognizes the following formal roles: a Developer, a Committer and a Maintainer. Informally, the Community may organize itself and give rights and responsibilities to the necessary people to achieve its goals.

  1. A Developer

    A Developer is anyone who wishes to contribute to the project, at any level. Developers are granted the following right to:

    • Contribute code, documentation, translations, artwork, etc,.
    • Report defects(bugs) and suggestions for enhancements;
    • Participate in the process of reviewing contributions by others;
    • Initiate and participate in discussions in communication channels.

    Developers are required to:

    • Abide by decisions, once made. They are welcome to provide new, relevant information to reopen decisions;
    • Assume responsibility for issues and bugs introduced by one's own contributions;
    • Respect the 'Rules of Community'(see below);
    • Provide constructive advices whenever participating in discussions and in the review of contributions.

  2. A Committer

    A Committer is a Developer who is also responsible for the maintenance of a particular area of code or of a source code repository. Committers have the following rights and responsibilities, in addition to those listed for Developers:

    • Right to set goals for the short and medium terms for the repository being maintained;
    • Responsibility to ensure all contributions to the repository have been reviewed within reasonable time;
    • Responsibility to monitor discussions in the Community.

  3. A Maintainer

    A Maintainer is a Developer who is also responsible for knowing, directing and anticipating the needs of a given repository. Maintainers have the following rights and responsibilities, in addition to those listed for Committers:

    • Right to set the overall organization of the source code in the repository;
    • Right and responsibility to lead the feature development discussion;
    • Responsibility to ensure the quality of the code to expected levels;
    • Responsibility to participate in the quality verification and release process, when those happen.
    • Responsibility of a representative of the Community;
    • Maximum 2 Maintainers are allowed per Community.

    A Maintainer is not a mandatory role of Samsung Inner Source Governance. When the Community decide to go without the role title of a Maintainers, one of the Committer of the Community SHOULD take the written roles and responsibilities of a Maintainer in Samsung Inner Source Governance.

  4. A Benevolent-Leader

    A Benevolent-Leader is a member of the Community who has the final saying in the case of disputes. This is a model followed by many successful Open Source projects, and they are sometimes called the "benevolent dictator". The Benevolent-Leader has the following responsibilities:

    • Govern Samsung Inner Source Program;
    • Make calm controversy in Communities and a Program itself.

    A Benevolent-Leader refers to the role, not a person.

  5. An Administrator

    An Administrator is a member who help operate and gear to healthy Samsung Inner Source Program. Samsung Inner Source Portal is operated by the Administrator.

  6. Selection of Committers and Maintainers

    A candidate for the Committer role should be one of the Developers who has submitted at least 10 non-trivial patches in that repository and has shown characteristics consistent with the requirements of the Committer role. To be a candidate for the Committer or the Maintainer, a Developer can self-nominate with proper evidences.

    The selection process SHOULD be archived by consensus of the Developers active, Committers and Maintainers in that repository. If consensus cannot be achieved, the Benevolent-Leader will make the decision and all decisions MUST be ratified by the Benevolent-Leader.

  7. Revocation of Committers/Maintainers status

    A Maintainer or a Committer who intentionally abuses his review privilege may have it temporarily suspended on the request of other Committers or Maintainers. Committers and Maintainers not including the person under consideration should discuss on the revocation of the person. If consensus cannot be reached, the Benevolent-Leader will make the decision and all decisions MUST be ratified by the Benevolent-Leader.

3. Rules of Community

  1. Samsung Inner Source Program aims for OPEN COLLABORATION.

    1. Egalitarian, Every contributors who is willing to help a project should be welcome.
    2. Contributions to projects should be judged meritocracy based on the value they bring to the project. For transparency, all the merits SHOULD be come with OPEN COMMUNICATION (decisions should be discussed publicly).
    3. A Community is an individual organizational unit.

    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 MUST not be tolerated.

  2. All Community members must adhere to these simple rules:

    1. Respect and acknowledge all contributions, suggestions and comments from the Community;
    2. Listen and be open to all opinions, which are subject to open discussion;
    3. Help each other and the other developers;
    4. Assume people mean well;
    5. Be humble and bold.

  3. Lazy Consensus and Silent Consent

    1. Lazy Consensus means that developers may proceed with work when they have a reason to believe that other Developers in the Community will agree with the direction, and need not stop to initiate unnecessary discussions about the work. In this case, they should publish their work rapidly (that is, merge proposals to version control) to allow others to raise objections when there are any. When the developer is not sure there will be consensus, they should raise a proposal on the appropriate communication channels. The Silent Consent principle will apply in this case.
    2. Silent Consent means that those who do not offer a reasoned alternative in course of the discussion implicitly agree with the proposal.
    3. These principles are valid for OPEN DISCUSSIONS in the Github Issues and/or the Primary Communication Channel of the Community. Consensus reached in other ways (such as face-to face discussions or communication on other channels) are to be considered unapproved proposals until submitted to the relevant Github Issues and/or the Primary Communication Channel of the Community. Thus giving dissenting options the opportunity to be voiced.

  4. Decision Making in the Samsung Inner Source Community

    1. Decisions are made always at the lowest level possible that is applicable for the decision in a question.
    2. Individual Developers are making decisions every time they submit changes.
    3. two or more Developers also make decisions when participating in an OPEN DISCUSSION. Their arguments in why a given decision should be made are part of the consensus that needs to be reached for the decision. Any of opinions SHOULD NOT be disregarded.
    4. If those Developers cannot agree and reach consensus on a decision, then the Benevolent-Leader WOULD mediates the situation, avoiding stalemates. Arbitration COULD made by voting of relevant Community members on the issue.
      • Decisions affecting a project are made by community members of the project.
      • Decisions that overlap more than one project are made in conjunction by community members of related projects.