Skip to content

GOVERNANCE.md

Latest commit

 

History

History
145 lines (98 loc) · 4.53 KB

GOVERNANCE.md

File metadata and controls

145 lines (98 loc) · 4.53 KB

Project Governance

This document describes the governance structure and decision-making processes for the NurOS project.

Project Name

NurOS is a GNU/Linux distribution developed as an open-source community project.

Roles and Responsibilities

Owner/BD (Benevolent Dictator)

The project leader(s) who make final decisions on project direction and disputes.

Responsibilities:

  • Approve or reject major project decisions
  • Resolve disputes and conflicts
  • Enforce project rules and Code of Conduct
  • Make final decisions on appeals

Current Owner/BD: AnmiTaliDev

Important: Owner/BD decisions can be appealed if you can provide strong evidence and reasoning to support your case.

Maintainer

Component maintainers who oversee specific parts of the project.

Responsibilities:

  • Make decisions regarding their component
  • Review and merge contributions to their component
  • Consult with Owner/BD when needed
  • Maintain code quality and project standards

How to become a Maintainer:

  • Apply through become.nuros.org
  • Wait for vacancy announcements
  • Vote by existing team members

Inactivity policy: If a Maintainer has no contact (not just commits, but any communication) for 3 years, their rights are transferred to another developer.

Core Developers

Primary development team members who work on the project regularly.

Responsibilities:

  • Contribute code and improvements
  • Participate in technical decisions
  • Consult with Maintainers on component-related changes
  • Can make decisions independently, but Maintainer/Owner can appeal

How to become a Core Developer:

  • Apply through become.nuros.org
  • Wait for vacancy announcements
  • Vote by existing team members

Contributors

External or staff developers who contribute to the project.

Responsibilities:

  • Submit patches, bug fixes, and improvements
  • Propose new ideas and features
  • Communicate with Owner, Maintainers, and Core developers
  • Follow project guidelines

Limitations: Contributors cannot make final decisions but are encouraged to propose ideas and discuss them with the team.

Decision-Making Process

Regular Decisions

Most technical decisions are made by:

  1. Maintainers for their components
  2. Core Developers in consultation with Maintainers
  3. Owner/BD for project-wide matters

Voting

When consensus cannot be reached, voting is used:

Private voting (staff only):

  • Takes place in the private Telegram group
  • Only staff developers (Owner, Maintainers, Core developers) can vote
  • Simple majority (50% + 1) required to pass

Public voting:

  • Takes place in Telegram channel @nuros_tg
  • Any community member can participate
  • Used for community-wide discussions and non-binding polls

Appeals Process

Owner/BD decisions can be appealed if you disagree:

How to appeal:

  1. Contact Owner/BD directly through their GitHub profile (email or other contacts listed there)
  2. Appeals can be made publicly or privately
  3. You must provide evidence and reasoning - not just disagreement
  4. Owner/BD will reconsider based on the evidence presented

Note: There is no fixed timeline for appeal resolution. Be patient and provide complete information.

Conflict Resolution

When conflicts arise between developers:

  1. Debate - Discuss in project chats (public or private staff chat)
  2. Present evidence - Support your position with facts and reasoning
  3. Seek consensus - Try to find middle ground
  4. Vote - If consensus fails, use voting process above
  5. Owner decision - As final resort, Owner/BD makes the call

Preferred approach: Public discussion in community chats when possible, private staff discussions when sensitive.

Code of Conduct Enforcement

The project follows Contributor Covenant 3.0 Code of Conduct.

Violations are handled by:

  • Owner/BD makes final decisions on CoC violations
  • See ENFORCEMENT.md for specific procedures

Transparency

The project values openness:

  • Major decisions should be documented
  • Community should be informed of important changes
  • Voting results (when applicable) should be shared
  • Financial matters are documented in DONATIONS.md

Changes to Governance

This governance document can be modified by:

  • Owner/BD decision, or
  • Majority vote of staff developers in private group

Proposed changes should be discussed with the community before implementation.

Questions? Contact the project team through:

  • Telegram: @nuros_tg
  • GitHub: Open an issue in the main repository
  • Email: Check maintainer contacts in their GitHub profiles