Skip to content

Commit 4607d46

Browse files
romanbaronEkinKarabulutitsomri
authored
added contributing, maintainer and owners files (#74)
* added contributing, maintainer and owners files * added code of conduct * added governance doc * Adding link to code_of_conduct.md in CONTRIBUTING.md * code and documentation change in contributing.md * edited MAINTAINERS.md * edited maintenrs.md * Added roadmap to README.md * Docs enhancement * Added explenation on changelogging (#121) * Update CONTRIBUTING.md Co-authored-by: Omri Cohen <[email protected]> * Fixed typo in CONTRIBUTING doc * Updated roadmap in README doc --------- Co-authored-by: EkinKarabulut <[email protected]> Co-authored-by: Omri Cohen <[email protected]>
1 parent 7e1cffe commit 4607d46

File tree

7 files changed

+299
-26
lines changed

7 files changed

+299
-26
lines changed

‎CLA.md‎

Lines changed: 34 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,34 @@
1+
Developer Certificate of Origin
2+
Version 1.1
3+
4+
Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
5+
6+
Everyone is permitted to copy and distribute verbatim copies of this
7+
license document, but changing it is not allowed.
8+
9+
10+
Developer's Certificate of Origin 1.1
11+
12+
By making a contribution to this project, I certify that:
13+
14+
(a) The contribution was created in whole or in part by me and I
15+
have the right to submit it under the open source license
16+
indicated in the file; or
17+
18+
(b) The contribution is based upon previous work that, to the best
19+
of my knowledge, is covered under an appropriate open source
20+
license and I have the right under that license to submit that
21+
work with modifications, whether created in whole or in part
22+
by me, under the same open source license (unless I am
23+
permitted to submit under a different license), as indicated
24+
in the file; or
25+
26+
(c) The contribution was provided directly to me by some other
27+
person who certified (a), (b) or (c) and I have not modified
28+
it.
29+
30+
(d) I understand and agree that this project and the contribution
31+
are public and that a record of the contribution (including all
32+
personal information I submit with it, including my sign-off) is
33+
maintained indefinitely and may be redistributed consistent with
34+
this project or the open source license(s) involved.

‎CONTRIBUTING.md‎

Lines changed: 43 additions & 25 deletions
Original file line numberDiff line numberDiff line change
@@ -1,34 +1,52 @@
1-
Developer Certificate of Origin
2-
Version 1.1
1+
# Contributing to KAI Scheduler
32

4-
Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
3+
Thank you for your interest in contributing to KAI Scheduler! This document provides guidelines and instructions to help you get started with contributing to our project.
54

6-
Everyone is permitted to copy and distribute verbatim copies of this
7-
license document, but changing it is not allowed.
5+
Make sure to read our [Contributor License Agreement](CLA.md) and [Code of Conduct](code_of_conduct.md).
86

7+
## Getting Started
8+
### New Contributors
9+
We're excited to help you make your first contribution! Whether you're looking to file issues, develop features, fix bugs, or improve documentation, we're here to support you through the process.
910

10-
Developer's Certificate of Origin 1.1
11+
Browse issues labeled [good first issue] or [help wanted] on GitHub for an easy introduction.
1112

12-
By making a contribution to this project, I certify that:
13+
### Developers
14+
The main building blocks of KAI Scheduler are documented in the `docs/developer` folder. Here are the key components:
15+
- [Action Framework](docs/developer/action-framework.md) - Core scheduler logic
16+
- [Plugin Framework](docs/developer/plugin-framework.md) - Extensible plugin system
17+
- [Pod Grouper](docs/developer/pod-grouper.md) - Group scheduling functionality
18+
- [Binder](docs/developer/binder.md) - Binding logic
1319

14-
(a) The contribution was created in whole or in part by me and I
15-
have the right to submit it under the open source license
16-
indicated in the file; or
20+
We recommend reviewing these documents to understand the system architecture before making significant contributions.
1721

18-
(b) The contribution is based upon previous work that, to the best
19-
of my knowledge, is covered under an appropriate open source
20-
license and I have the right under that license to submit that
21-
work with modifications, whether created in whole or in part
22-
by me, under the same open source license (unless I am
23-
permitted to submit under a different license), as indicated
24-
in the file; or
22+
## How to Contribute
23+
### Reporting Issues
24+
Open an issue with a clear description, steps to reproduce, and relevant environment details.
2525

26-
(c) The contribution was provided directly to me by some other
27-
person who certified (a), (b) or (c) and I have not modified
28-
it.
26+
### Improving Documentation
27+
Help us keep the docs clear and useful by fixing typos, updating outdated information, or adding examples.
2928

30-
(d) I understand and agree that this project and the contribution
31-
are public and that a record of the contribution (including all
32-
personal information I submit with it, including my sign-off) is
33-
maintained indefinitely and may be redistributed consistent with
34-
this project or the open source license(s) involved.
29+
### Contributing changes
30+
- Fork and Clone – Begin by forking the repository and cloning it to your local machine.
31+
- Create a Branch – Use a descriptive branch name, such as feature/add-cool-feature or bugfix/fix-issue123.
32+
- Make Changes – Keep your commits small, focused, and well-documented. For detailed build and test instructions, refer to [Building from Source](docs/developer/building-from-source.md).
33+
- Log Changes – For behavior-affecting changes (features, fixes, API changes), update the [changelog](CHANGELOG.md) file under the "Unreleased" section. Follow the format at [keepachangelog.com](https://keepachangelog.com/en/1.1.0/). Skip logging internal changes like refactoring or tests.
34+
- Submit a PR – Open a pull request and reference any relevant issues or discussions.
35+
36+
### Pull Request Checklist
37+
Before introducing major changes, we strongly recommend opening a PR that outlines your proposed design.
38+
Each pull request should meet the following requirements:
39+
- All tests pass – Run the full test suite locally with: `make build validate test`
40+
- Test coverage – Add or update tests for any affected code.
41+
- Documentation – Update relevant documentation to reflect your changes.
42+
- Changes logged - If your changes warrant logging - like behavior changes (including bugfixes) or new features - add them to the [Changelog](CHANGELOG.md)
43+
44+
## Getting Help
45+
Need support or have a question? We're here to help:
46+
- Report issues or ask questions by [opening an issue on GitHub](https://github.com/NVIDIA/KAI-Scheduler/issues).
47+
- Join the conversation in the [#batch-wg](https://cloud-native.slack.com/archives/C02Q5DFF3MM) Slack channel to connect with the community and contributors.
48+
49+
## License
50+
By contributing, you agree that your contributions will be licensed under the Apache License 2.0.
51+
52+
Thank you for your interest and happy coding!

‎GOVERNANCE.md‎

Lines changed: 127 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,127 @@
1+
# Project Governance
2+
3+
This document outlines the governance model for the project, including roles and responsibilities, decision-making processes, and procedures for community participation.
4+
The goal is to provide a transparent and inclusive framework that supports collaboration, innovation, and accountability.
5+
6+
## Introduction
7+
8+
This governance model applies to the KAI Scheduler project.
9+
It serves as a guide to ensure clarity and consistency in the way decisions are made, contributors are supported, and the project grows in a sustainable and inclusive manner.
10+
11+
## Roles & Responsibilities
12+
13+
### Maintainers
14+
15+
Maintainers are the individuals responsible for the long-term health and direction of the project.
16+
They have the final say on key decisions but are expected to collaborate with the community and seek consensus when possible.
17+
18+
- **Responsibilities**:
19+
- Oversee the technical direction of the project.
20+
- Make final decisions on contributions and community matters.
21+
- Ensure code quality and maintainability.
22+
- Manage project releases and documentation.
23+
- Resolve conflicts and mediate disputes within the community.
24+
- Actively participate in community discussions.
25+
26+
### Contributors
27+
28+
Contributors are individuals who actively participate in the project by submitting code, bug reports, documentation, or other contributions.
29+
Contributors may be individuals, teams, or organizations.
30+
31+
- **Responsibilities**:
32+
- Follow the project’s guidelines for contributions.
33+
- Engage in discussions and provide feedback on project decisions.
34+
- Respect the project's code of conduct.
35+
- Strive for high-quality contributions that adhere to the project's goals.
36+
37+
### Community
38+
39+
The community consists of all individuals interested in the project, including end users, contributors, and other stakeholders.
40+
The community is encouraged to contribute ideas, report issues, and engage in discussions.
41+
42+
- **Responsibilities**:
43+
- Provide feedback on project decisions and contribute to discussions.
44+
- Participate in community events and initiatives.
45+
- Respect the project’s code of conduct.
46+
47+
## Decision-Making Process
48+
49+
### Core Decisions
50+
51+
Core decisions, such as changes to the overall direction of the project, architectural shifts, or the approval of major features, are made by the maintainers.
52+
53+
- **Process**:
54+
- A proposal for a major change will be submitted as a pull request or issue.
55+
- The maintainers will discuss the proposal and seek feedback from the community.
56+
- Once the discussion is concluded, maintainers will make the final decision.
57+
58+
### Day-to-Day Decisions
59+
60+
Day-to-day decisions, such as merging pull requests or handling smaller contributions, are made by the [approvers](OWNERS).
61+
These decisions should be made as quickly as possible to avoid delays in development.
62+
63+
- **Process**:
64+
- Contributors submit a pull request with their proposed changes.
65+
- Approvers review and approve the pull request if it meets the project’s standards.
66+
- Minor changes, such as documentation updates or bug fixes, may be handled without a formal discussion.
67+
68+
### Dispute Resolution
69+
70+
If there is a disagreement or conflict within the community, it will be resolved through discussion and mediation.
71+
72+
- **Process**:
73+
- Disputes should be addressed privately first through direct communication.
74+
- If the dispute cannot be resolved, a maintainer will mediate the discussion.
75+
- As a last resort, the maintainer team may make a final decision to resolve the issue.
76+
77+
## Community Guidelines
78+
79+
### Code of Conduct
80+
81+
All contributors are expected to follow the [Code of Conduct](code_of_conduct.md).
82+
This ensures a welcoming and respectful environment for all participants.
83+
84+
### Contribution Guidelines
85+
86+
To contribute to the project, follow the guidelines outlined in the [CONTRIBUTING.md](CONTRIBUTING.md).
87+
This document details the process for submitting issues, pull requests, and providing feedback.
88+
89+
### Communication
90+
91+
- **Channels**: The primary channels for communication within the project are GitHub issues and discussions pages in the repository and [#batch-wg](https://cloud-native.slack.com/archives/C02Q5DFF3MM) Slack channel.
92+
- **Expected Behavior**: Be respectful, professional, and collaborative in all interactions. Discriminatory behavior, harassment, and disruptive actions will not be tolerated.
93+
94+
## Elections
95+
96+
### Maintainer Elections
97+
98+
Maintainers are selected through a transparent and community-driven process.
99+
When a maintainer position becomes open, the existing maintainers will suggest potential candidates from within the community.
100+
101+
- **Process**:
102+
- Existing maintainers propose candidates based on their contributions and involvement in the project.
103+
- The community is invited to provide feedback on the suggested candidates.
104+
- After considering community feedback, the maintainers make the final decision to invite the selected candidates to join the maintainer team.
105+
106+
## Project Health
107+
108+
### Reporting
109+
110+
The project’s health and progress should be regularly reported to the community. This includes updates on releases, upcoming features, and current issues.
111+
112+
- **Process**:
113+
- Regular updates will be provided in the form of **release notes**, **roadmap updates**, and **issue tracking**.
114+
- The maintainer team will host periodic community meetings to discuss the project’s status.
115+
116+
### Code of Conduct Violations
117+
118+
If any member of the community violates the code of conduct, they may be subject to sanctions, including temporary or permanent bans from the project.
119+
120+
- **Process**:
121+
- Violations should be reported to a maintainer or the community manager.
122+
- A review will be conducted, and if the violation is confirmed, appropriate actions will be taken, including warning, suspension, or ban.
123+
124+
## Conclusion
125+
126+
This governance model provides a framework for maintaining a healthy, open, and collaborative project.
127+
It is designed to evolve as the project grows and should be reviewed periodically to ensure it remains relevant and effective.

‎MAINTAINERS.md‎

Lines changed: 12 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,12 @@
1+
The current Maintainers Group for KAI Scheduler project consists of:
2+
3+
| Maintainer | GitHub ID | Affiliation |
4+
|-----------------|-------------------------------------------------------|-------------|
5+
| Roman Baron | [romanbaron](https://github.com/romanbaron) | NVIDIA |
6+
| Omer Dayan | [omer-dayan](https://github.com/omer-dayan) | NVIDIA |
7+
| Omri Cohen | [itsomri](https://github.com/itsomri) | NVIDIA |
8+
| Erez Freiberger | [enoodle](https://github.com/enoodle) | NVIDIA |
9+
| David Lifshitz | [davidLif](https://github.com/davidLif) | NVIDIA |
10+
| Daniel Keinan | [keinandaniel](https://github.com/keinandaniel) | NVIDIA |
11+
| Ekin Karabulut | [EkinKarabulut](https://github.com/EkinKarabulut) | NVIDIA |
12+
| Hagay Sharon | [Hagay-RunAI](https://github.com/Hagay-RunAI) | NVIDIA |

‎OWNERS‎

Lines changed: 7 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,7 @@
1+
approvers:
2+
- romanbaron
3+
- omer-dayan
4+
- itsomri
5+
- enoodle
6+
- davidLif
7+
- keinandaniel

‎README.md‎

Lines changed: 23 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -50,9 +50,31 @@ Follow the instructions [here](docs/developer/building-from-source.md)
5050
## Quick Start
5151
To start scheduling workloads with KAI Scheduler, please continue to [Quick Start example](docs/quickstart/README.md)
5252

53+
## Roadmap
54+
55+
### High-level overview of the main priorities for 2025
56+
* Refactor the codebase to enhance vendor neutrality
57+
* Support Scheduling Gates https://github.com/NVIDIA/KAI-Scheduler/issues/63
58+
* Research on possible integration with Kueue https://github.com/NVIDIA/KAI-Scheduler/issues/68
59+
* Add Topology Aware Scheduling support of pod-group https://github.com/NVIDIA/KAI-Scheduler/issues/66
60+
* Support Min Run Time per workloads
61+
* Support Max Run Time per workload (with delayed requeue)
62+
* Add more PriorityClasses as part of the default KAI install
63+
* Support JobSet
64+
* Support LWS (LeaderWorkerSet)
65+
* Add metrics for pod and pod-group preemptions
66+
* Decouple Priority and Preemption
67+
68+
### Long term goals
69+
* Support per queue time decay
70+
* Hyper scale improvements
71+
* Support Consolidation of Inference workloads for cluster defragmentation
72+
* Support n-levels of hierarchical queues
73+
* Graceful rollout of Inference workloads (new revision update using queue temporary over-quota)
74+
5375
## Support and Getting Help
5476
We’d love to hear from you! Here's how to reach out:
5577

5678
- Technical Questions, Bugs, and Feature Requests: Please open [an issue on GitHub](https://github.com/NVIDIA/KAI-scheduler/issues/new) for anything related to technical support, bug reports, or feature suggestions. This helps us track and address them efficiently.
57-
- General Discussion & Roadmap Topics: For broader conversations—like roadmap discussions, scheduling strategies, or working group coordination—join the [CNCF Slack workspace](https://communityinviter.com/apps/cloud-native/cncf) and drop by the #batch-wg channel.
79+
- For broader conversations, including roadmap planning, scheduling strategies, and working group coordination, join the [CNCF Slack workspace](https://communityinviter.com/apps/cloud-native/cncf) and visit the [#batch-wg](https://cloud-native.slack.com/archives/C02Q5DFF3MM) channel.
5880

‎code_of_conduct.md‎

Lines changed: 53 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,53 @@
1+
# Code of Conduct
2+
3+
## Our Pledge
4+
5+
We are committed to providing a welcoming, inclusive, and harassment-free environment for all participants.
6+
This includes respecting individuals of all backgrounds, identities, and experiences—regardless of age, disability, ethnicity, gender identity and expression, education level, socio-economic status, nationality, personal appearance, race, religion, or sexual orientation.
7+
8+
## Our Standards
9+
10+
Examples of behavior that contributes to a positive environment include:
11+
12+
- Being respectful and considerate of differing viewpoints and experiences
13+
- Gracefully accepting constructive criticism
14+
- Focusing on what is best for the community
15+
- Showing empathy and kindness toward other community members
16+
- Using welcoming and inclusive language
17+
18+
Examples of unacceptable behavior include:
19+
20+
- Trolling, insulting or derogatory comments, and personal or political attacks
21+
- Public or private harassment
22+
- Publishing others’ private information without explicit permission
23+
- Unwelcome sexual attention or advances
24+
- Disruptive behavior in meetings, communications, or online platforms
25+
26+
## Our Responsibilities
27+
28+
Project maintainers are responsible for:
29+
30+
- Clearly communicating the standards of acceptable behavior
31+
- Enforcing the Code of Conduct fairly and consistently
32+
- Investigating reported violations in a timely and respectful manner
33+
- Taking appropriate corrective action when necessary, including removing or modifying content not aligned with the Code
34+
35+
Maintainers also have the authority to define and clarify what constitutes official representation of the project.
36+
37+
## Scope
38+
39+
This Code of Conduct applies in all project spaces, including:
40+
41+
- Repositories and code contributions
42+
- Issue trackers and pull requests
43+
- Communication channels (e.g., Slack, Email)
44+
- Community meetings and events (virtual or in-person)
45+
46+
## Enforcement
47+
48+
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project maintainers team.
49+
All complaints will be reviewed and investigated promptly and fairly. All maintainers are obligated to respect the privacy and security of the reporter.
50+
51+
## Attribution
52+
53+
This Code of Conduct is adapted from the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md)

0 commit comments

Comments
 (0)