Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions .github/ISSUE_TEMPLATE/config.yml
Original file line number Diff line number Diff line change
@@ -1,8 +1,8 @@
blank_issues_enabled: false
contact_links:
- name: Questions & Discussion
url: https://github.com/llm-d/llm-d/discussions
url: https://github.com/llm-d/llm-d/issues
about: Ask questions and discuss ideas in the llm-d community
- name: Slack
url: https://cloud-native.slack.com/archives/llm-d
url: https://llm-d.ai/slack
about: Chat with the community on Slack
36 changes: 2 additions & 34 deletions CODE_OF_CONDUCT.md
Original file line number Diff line number Diff line change
@@ -1,34 +1,2 @@
## Code of Conduct and Covenant

## Our Pledge

In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.

## Our Standards

Examples of behavior that contributes to creating a positive environment include:

* Using welcoming and inclusive language
* Being respectful of differing viewpoints and experiences
* Gracefully accepting constructive criticism
* Focusing on what is best for the community
* Showing empathy towards other community members

Examples of unacceptable behavior by participants include:

* The use of sexualized language or imagery and unwelcome sexual attention or advances
* Trolling, insulting/derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or electronic address, without explicit permission
* Other conduct which could reasonably be considered inappropriate in a professional setting

## Our Responsibilities

Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.

## Scope

This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.Attribution
This Code of Conduct is adapted from the Contributor Covenant, version 1.4, available at <https://www.contributor-covenant.org/version/1/4/code-of-conduct.html>

For answers to common questions about this code of conduct, see <https://www.contributor-covenant.org/faq>
# Code of Conduct
This project follows the llm-d Code of Conduct. Please see the [llm-d Code of Conduct](https://github.com/llm-d/llm-d/blob/main/CODE_OF_CONDUCT.md) in the main repository.
101 changes: 2 additions & 99 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
@@ -1,99 +1,2 @@
## Contributing Guidelines

Thank you for your interest in contributing to this project. Community involvement is highly valued and crucial for the project's growth and success. This project accepts contributions via GitHub pull requests. This document outlines the process to help get your contribution accepted.

To ensure a clear direction and cohesive vision for the project, the project leads have the final decision on all contributions. However, these guidelines outline how you can contribute effectively.

## How You Can Contribute

There are several ways you can contribute:

* **Reporting Issues:** Help us identify and fix bugs by reporting them clearly and concisely.
* **Suggesting Features:** Share your ideas for new features or improvements.
* **Improving Documentation:** Help make the project more accessible by enhancing the documentation.
* **Submitting Code Contributions:** Code contributions that align with the project's vision are always welcome.

## Code of Conduct

This project adheres to the [Code of Conduct and Covenant](CODE_OF_CONDUCT.md). By participating, you are expected to uphold this code.

## Community and Communication

* **Developer Slack:** [Join our developer Slack workspace](https://llm-d.ai/slack) to connect with the core maintainers and other contributors, ask questions, and participate in discussions.
* **Weekly Meetings:** Project updates, ongoing work discussions, and Q&A will be covered in our weekly project meetings. Please join by [adding the shared calendar](https://red.ht/llm-d-public-calendar). You can also [join our Google Group](https://groups.google.com/g/llm-d-contributors) for access to shared content.
* **Code:** Hosted in the [llm-d](https://github.com/llm-d) GitHub organization
* **Issues:** Project-scoped bugs or issues should be reported in this repo or in [llm-d/llm-d](https://github.com/llm-d/llm-d)
* **Mailing List:** [llm-d-contributors@googlegroups.com](mailto:llm-d-contributors@googlegroups.com)

## Contributing Process

We follow a **lazy consensus** approach: changes proposed by people with responsibility for a problem, without disagreement from others, within a bounded time window of review by their peers, should be accepted.

### Types of Contributions

#### 1. Features with Public APIs or New Components

All features involving public APIs, behavior between core components, or new core subsystems must be accompanied by an **approved project proposal**.

**Process:**

1. Create a pull request adding a proposal document under `./docs/proposals/` with a descriptive name
2. Include these sections: Summary, Motivation (Goals/Non-Goals), Proposal, Design Details, Alternatives
3. Get review from impacted component maintainers
4. Get approval from project maintainers

#### 2. Fixes, Issues, and Bugs

For changes that fix broken code or add small changes within a component:

* All bugs and commits must have a clear description of the bug, how to reproduce, and how the change is made
* Any other changes can be proposed in a pull request — a maintainer must approve the change
* For moderate size changes, create an RFC issue in GitHub, then engage in Slack

## Code Review Requirements

* **All code changes** must be submitted as pull requests (no direct pushes)
* **All changes** must be reviewed and approved by a maintainer other than the author
* **All repositories** must gate merges on compilation and passing tests
* **All experimental features** must be off by default and require explicit opt-in

## Commit and Pull Request Style

* **Pull requests** should describe the problem succinctly
* **Rebase and squash** before merging
* **Use minimal commits** and break large changes into distinct commits
* **Commit messages** should have:
* Short, descriptive titles
* Description of why the change was needed
* Enough detail for someone reviewing git history to understand the scope
* **DCO Sign-off**: All commits must include a valid DCO sign-off line (`Signed-off-by: Name <email@domain.com>`)
* Add automatically with `git commit -s`
* See [PR_SIGNOFF.md](PR_SIGNOFF.md) for configuration details
* Required for all contributions per [Developer Certificate of Origin](https://developercertificate.org/)

## Code Organization and Ownership

* **Components** are the primary unit of code organization
* **Maintainers** own components and approve changes
* **Contributors** can become maintainers through sufficient evidence of contribution
* Code ownership is reflected in [OWNERS files](https://go.k8s.io/owners) consistent with Kubernetes project conventions

## Testing Requirements

We use three tiers of testing:

1. **Unit tests**: Fast verification of code parts, testing different arguments
2. **Integration tests**: Testing protocols between components and built artifacts
3. **End-to-end (e2e) tests**: Whole system testing including benchmarking

Strong e2e coverage is required for deployed systems to prevent performance regression. Appropriate test coverage is an important part of code review.

## Security

See [SECURITY.md](SECURITY.md) for our vulnerability disclosure process.

## API Changes and Deprecation

* **No breaking changes**: Once an API/protocol is in GA release, it cannot be removed or behavior changed
* **Versioning**: All protocols and APIs should be versionable with clear compatibility requirements
* **Documentation**: All APIs must have documented specs describing expected behavior
# Contributing Guidelines
Please see the [llm-d Contributing Guidelines](https://github.com/llm-d/llm-d/blob/main/CONTRIBUTING.md) in the main repository.
Loading
Loading