GOVERNANCE.md

Rama main · réplica de lectura del repositorio original.

# Isola Project Governance

The Isola project is dedicated to providing secure, self-hosted sandboxing for
untrusted and AI-generated code on Kubernetes. This governance explains how
the project is run. It follows the
[CNCF maintainer-council governance template](https://github.com/cncf/project-template/blob/main/GOVERNANCE-maintainer.md),
adapted to the project's current size.

- [Values](#values)
- [Maintainers](#maintainers)
- [Becoming a Maintainer](#becoming-a-maintainer)
- [Removing a Maintainer](#removing-a-maintainer)
- [Decision Making and Voting](#decision-making-and-voting)
- [Code of Conduct Enforcement](#code-of-conduct-enforcement)
- [Security Response](#security-response)
- [Modifying this Charter](#modifying-this-charter)

## Values

The Isola project and its leadership embrace the following values:

- **Openness**: Communication and decision-making happen in the open and are
  discoverable for future reference. As much as possible, all discussions and
  work take place in public forums and open repositories.

- **Fairness**: All stakeholders have the opportunity to provide feedback and
  submit contributions, which will be considered on their merits.

- **Community over Product or Company**: Sustaining and growing our community
  takes priority over shipping code or any sponsor's organizational goals.
  Each contributor participates in the project as an individual.

- **Inclusivity**: We innovate through different perspectives and skill sets,
  which can only be accomplished in a welcoming and respectful environment.

- **Participation**: Responsibilities within the project are earned through
  participation, and there is a clear path for contributors to grow into
  leadership positions.

## Maintainers

Isola Maintainers have write access to the
[project GitHub repository](https://github.com/isola-run/isola). They can
merge their own patches or patches from others. The current maintainers can
be found in [MAINTAINERS.md](MAINTAINERS.md). Maintainers collectively manage
the project's resources and contributors.

This privilege is granted with some expectation of responsibility:
maintainers are people who care about the Isola project and want to help it
grow and improve. A maintainer is not just someone who can make changes, but
someone who has demonstrated the ability to collaborate with the team, get
the most knowledgeable people to review code and docs, contribute
high-quality code, and follow through to fix issues in code or tests.

The collective team of all Maintainers is known as the Maintainer Council,
which is the governing body for the project.

## Becoming a Maintainer

To become a Maintainer you need to demonstrate the following:

- Commitment to the project:
  - participate in discussions, contributions, and code and documentation
    reviews for three months or more,
  - perform reviews for several non-trivial pull requests,
  - contribute several non-trivial pull requests and have them merged.
- Ability to write quality code and/or documentation.
- Ability to collaborate with the team.
- Understanding of how the team works (policies, processes for testing and
  code review).
- Understanding of the project's code base and coding and documentation
  style.

A new Maintainer must be proposed by an existing maintainer by opening a
GitHub issue or discussion. A simple majority vote of existing Maintainers
approves the application. Maintainer nominations are evaluated without
prejudice to employer or demographics.

Maintainers who are selected will be granted the necessary GitHub rights and
added to [MAINTAINERS.md](MAINTAINERS.md).

## Removing a Maintainer

Maintainers may resign at any time if they feel that they will not be able to
continue fulfilling their project duties; they are then moved to emeritus
status in [MAINTAINERS.md](MAINTAINERS.md).

Maintainers may also be removed after being inactive, failing to fulfill
their maintainer responsibilities, violating the Code of Conduct, or for
other reasons. Inactivity is defined as a period of very low or no activity
in the project for a year or more, with no definite schedule to return to
full maintainer activity.

A Maintainer may be removed at any time by a 2/3 vote of the remaining
maintainers. While the Maintainer Council has fewer than three members,
involuntary removal additionally requires either documented inactivity as
defined above or a Code of Conduct violation; this prevents a single
maintainer from unilaterally removing another. Depending on the reason for
removal, a Maintainer may be converted to emeritus status. Emeritus Maintainers will still be consulted on
some project matters and can be rapidly returned to Maintainer status if
their availability changes.

## Decision Making and Voting

The project does not hold regular synchronous meetings; development and
decision-making happen asynchronously on GitHub issues, pull requests, and
[discussions](https://github.com/isola-run/isola/discussions).

Most business is conducted by
[lazy consensus](https://community.apache.org/committers/lazyConsensus.html):
a change is accepted when it is approved by at least one maintainer other
than its author and no maintainer objects within a reasonable review period.
While the project has a single maintainer, that maintainer's own changes are
accepted after CI passes and a reasonable period for community objection;
growing the Maintainer Council so that every change receives independent
review is an explicit project goal (see [ROADMAP.md](ROADMAP.md)).

Periodically, the Maintainers may need to vote on specific actions or
changes. Votes are taken on a GitHub issue or pull request, or privately by
email for security or conduct matters. Any Maintainer may demand a vote be
taken. Most votes require a simple majority of all Maintainers to succeed,
except where otherwise noted. Two-thirds majority votes mean at least
two-thirds of all existing maintainers.

## Code of Conduct Enforcement

[Code of Conduct](CODE_OF_CONDUCT.md) violations by community members are
discussed and resolved privately by the Maintainers. If a Maintainer is
directly involved in the report, the remaining Maintainers will handle it
without that Maintainer's participation. If the project joins a foundation,
a neutral escalation path (such as the CNCF Code of Conduct Committee) will
be added for reports that cannot be handled within the Maintainer Council.

## Security Response

The Maintainers are collectively responsible for handling all reports of
security vulnerabilities according to the
[security policy](SECURITY.md). As the project grows, the Maintainers may
appoint a dedicated Security Response Team of at least two contributors and
will review this assignment at least once a year.