1 - Governance
Code of Conduct
Lima follows the CNCF Code of Conduct.
Maintainership
Lima is governed by Maintainers who are elected from active contributors.
As a Cloud Native Computing Foundation project, Lima will keep its vendor-neutrality.
Roles
Maintainers consist of two roles:
Access control is enforced via GitHub team membership:
- All committers are members of the
@lima-vm/committers team and have the Maintain role on all repos. - All reviewers are members of the
@lima-vm/reviewers team and have the Triage role on all repos. - The
@lima-vm/maintainers team includes both committers and reviewers, but doesn’t grant any extra access.
See also the Contributing page.
Current maintainers
Emeritus maintainers
(No emeritus maintainers yet)
Addition and promotion of Maintainers
An active contributor to the project can be invited as a Reviewer,
and can be eventually promoted to a Committer after 2 months at least.
A contributor who have made significant contributions in quality and in quantity
can be also directly invited as a Committer.
A proposal to add or promote a Maintainer must be approved by 2/3 of the Committers who vote within 7 days.
Voting needs 2 approvals at least. The proposer can vote too.
A proposal should happen as a GitHub pull request to the Maintainer list above.
It is highly suggested to reach out to the Committers before submitting a pull request to check the will of the Committers.
Removal and demotion of Maintainers
A Maintainer who do not show significant activities for 6 months, or, who have been violating the Code of Conduct,
may be demoted or removed from the project.
A proposal to demote or remove a Maintainer must be approved by 2/3 of the Committers (excluding the person in question) who vote within 14 days.
Voting needs 2 approvals at least. The proposer can vote too.
A proposal may happen as a GitHub pull request, or, as a private discussion in the case of removal of a harmful Maintainer.
It is highly suggested to reach out to the Committers before submitting a pull request to check the will of the Committers.
Other decisions
Any decision that is not documented here can be made by the Committers.
When a dispute happens across the Committers, it will be resolved through a majority vote within the Committers.
A tie should be considered as a failed vote.
Release process
Eligibility to be a release manager:
- MUST be an active Committer
- MUST have the GPG fingerprint listed in the maintainer list above
- MUST upload the GPG public key to
https://github.com/USERNAME.gpg - MUST protect the GPG key with a passphrase or a hardware token.
Release steps:
- Open an issue to propose making a new release, e.g. https://github.com/lima-vm/lima/issues/2296.
The proposal should be public, with an exception for vulnerability fixes.
If this is the first time for you to take a role of release management,
you SHOULD make a beta (or alpha, RC) release as an exercise before releasing GA.
- Make sure that all the merged PRs are associated with the correct Milestone.
- Run
git tag --sign vX.Y.Z-beta.W . - Run
git push UPSTREAM vX.Y.Z-beta.W . - Wait for the
Release action on GitHub Actions to complete. A draft release will appear in https://github.com/lima-vm/lima/releases . - Download
SHA256SUMS from the draft release, and confirm that it corresponds to the hashes printed in the build logs on the Release action. - Sign
SHA256SUMS with gpg --detach-sign -a SHA256SUMS to produce SHA256SUMS.asc, and upload it to the draft release. - Add release notes in the draft release, to explain the changes and show appreciation to the contributors.
Make sure to fulfill the
Release manager: [ADD YOUR NAME HERE] (@[ADD YOUR GITHUB ID HERE]) line with your name.
e.g., Release manager: Akihiro Suda (@AkihiroSuda) . - Click the
Set as a pre-release checkbox if this release is a beta (or alpha, RC). - Click the
Publish release button. - Close the Milestone.
2 - Contributing
Reporting issues
Bugs and feature requests can be submitted via https://github.com/lima-vm/lima/issues.
For asking questions, use GitHub Discussions or Slack (#lima).
For reporting vulnerabilities, see https://github.com/lima-vm/.github/blob/main/SECURITY.md.
Contributing code
Getting Involved
We welcome new contributors! Here are some ways to get started and engage with the Lima community:
Introduce Yourself
Learn Where Work Is Needed
Find Open Issues
- Browse GitHub Issues labeled as
good first issue for tasks that are great for new contributors. - If you’re unsure where to start, ask in the community channels or open a new discussion.
We’re glad to have you here, your contributions make Lima better!
Sending pull requests
Pull requests can be submitted to https://github.com/lima-vm/lima/pulls. Please ensure that you are familiar with the below policies before submitting pull requests.
Talk first, code later
Before opening a pull request, open an issue first and explain your idea. Approval can be given as an approved comment, or by adding the ready-to-work label. It is okay to submit a pull request before the issue is approved, but keep in mind that unapproved work may not be merged and you risk wasting your effort.
Exceptions (issue is not required first):
- Pull requests from maintainers.
- Very small fixes (for example typos, or a pull request touching fewer than 2 files with about 10 lines of change.)
- Simple tool or dependency updates.
One fix per pull request
Each pull request should fix one specific thing. Do not mix unrelated changes in one pull request. For large, ground-breaking work that needs many changes to test CI or integration, a draft pull request is okay first. After that, split the work into smaller pull requests that depend on each other.
It is highly suggested to add tests for every non-trivial pull requests.
A test can be implemented as a unit test rather than an integration test when it is possible,
to avoid slowing the integration test CI.
Usually, all commits in a PR need to be squashed to a single commit before it can be merged. Rebase on the latest master branch in case GitHub shows that there are merge conflicts! For tips on squashing commits and rebasing before submitting your pull request, see Git Tips.
AI Contribution Rules
Lima welcomes help from AI tools, but we only accept high-quality pull requests. These rules help keep review time useful and fair for maintainers.
Humans are responsible for all content
All content in your pull request whether written directly by you or generated with AI tools must be reviewed and edited by you. You are responsible for ensuring the description is clear, accurate, and free of errors. It is often discouraged to have long AI-generated text blocks for pull request description, as reviewers need clear explanations directly from the contributor. When reviewers leave review comments, reply yourself without relying on AI tools.
Legal sign-off (DCO)
AI tools cannot legally sign off code. Only the human submitting the code can add a Signed-off-by line. See Developer Certificate of Origin below.
If you use AI-generated code, you must:
- Read and check all generated code before submitting.
- Add your own
Signed-off-by tag. - Take full responsibility for the submitted code.
Mention AI usage
If you used AI tools while preparing your pull request, disclose that in the pull request description using an Assisted-by: AI_TOOL_NAME trailer (see Linux kernel coding assistants policy). Co-Authored-By trailers added by AI tools are also acceptable and will not block a pull request from being merged.
Enforcement
Maintainers may close pull requests that do not follow these rules.
You can leave a comment in the pull request when you think it was closed inappropriately.
Licensing
Lima is licensed under the terms of Apache License, Version 2.0.
See also https://github.com/cncf/foundation/blob/main/policies-guidance/allowed-third-party-license-policy.md for third-party dependencies.
Developer Certificate of Origin (DCO)
Version 1.1
Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.
Developer’s Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
Every commit must be signed off with the Signed-off-by: REAL NAME <email@example.com> line.
Use the git commit -s command to add the Signed-off-by line.
See also https://github.com/cncf/foundation/blob/main/policies-guidance/dco-guidelines.md.
Merging pull requests
Committers can merge pull requests.
Reviewers can approve, but cannot merge, pull requests.
A Committer shouldn’t merge their own pull requests without approval by at least one other Maintainer (Committer or Reviewer).
This rule does not apply to trivial pull requests such as fixing typos, CI failures,
and updating image references in templates (e.g., https://github.com/lima-vm/lima/pull/2318).
3 - Roadmap
Instead of using a static text file, Lima uses the roadmap label on GitHub issues to designate features or bug fixes that we plan to implement.
Issues are tagged with the roadmap label when at least one maintainer or contributor has declared intent to work on or help with the implementation.
There are no commitments or timelines attached to the label, and the label may be removed again from an abandoned issue at any time.
Non-roadmap issues are kept open (as long as they fit the scope of the project) in case a volunteer one day appears and offers to work on them.
To find the items currently planned for Lima you can filter on open issues with the roadmap label.