This project is intended to be "very" open. Especially in the early stages, we do not have a lot of infrastructure in place to manage the repository, so we are relying on each other to be good collaborators. To that end, here are some guidelines for collaborating on this project.
Please read and internalize our code of conduct. We want this to be a welcoming and inclusive community, and we expect everyone to adhere to the code of conduct at all times. If you see someone violating the code of conduct, please report it to the maintainers immediately. We take all reports seriously and will take appropriate action to address any issues.
Open, direct, honest communication is encouraged, but always be respectful and professional.
This project is not limited to one timezone, and we hope to have collaborators from all over the world. Please be mindful of this at all times.
This project uses English as the primary language for communication. If English is not your first language, please do not hesitate to ask for clarification if you do not understand something.
Prefer written communication (PRs, issues, mailing-list, slack) over verbal communication (e.g. video calls). This allows for people who might not have been in the conversation to understand why a decision was made the way it was.
When writing, please strive for clarity and conciseness. Not everyone in the community will have the same proficiency in English, so please be mindful of that when writing.
Do not push directly to the main branch. Always use pull requests to propose changes to the codebase. This allows for code review and discussion before changes are merged, which helps maintain the quality of the codebase and fosters collaboration.
PRs should be merged by the reviewer of a PR, not the author.
For the time being, the Substrate project uses the same AI contribution policy as the Kubernetes project:
Using AI tools to help write your PR is acceptable, but as the author, you are responsible for understanding every change. If you used AI tools in preparing your PR, you must disclose this in the description of your PR. Listing AI tooling as a co-author, co-signing commits using an AI tool, or using the assisted-by, co-developed or similar commit trailer is not allowed.
All contributions must follow the contributions policies and use commit messages that align with the policy.
Large AI generated PRs and AI generated commit messages are not allowed.
Do not leave the first review of AI generated changes to the reviewers. Verify the changes (code review, testing, etc.) before submitting your PR. Reviewers may ask questions about your AI-assisted code, and if you cannot explain why a change was made, the PR will be closed.
When responding to review comments, you must do so without relying on AI tools. Reviewers want to engage directly with you, not with generated responses. If you do not engage directly with reviewers, the PR will be closed.
We want to move quickly, but we need to balance that with quality and maintainability. Code reviews are an important part of that process. All PRs should be reviewed BEFORE they are merged.
As this community grows, we expect to see collaborators from different companies. Whenever possible, we want to encourage code reviews across companies. This helps foster collaboration and knowledge sharing across the community, and it helps prevent silos from forming within the community.
We want to move quickly, but we also want to be respectful of each other's time. For the sake of consistency, this project's "working hours" are Monday to Friday, 8am to 8pm, US Pacific Time (GMT-7). Please avoid merging PRs late at night or on weekends, unless it is an urgent fix. This allows for people to have a better work-life balance and prevents burnout. If you do need to merge something outside of normal working hours, please try to give a heads up to the rest of the community so that they are aware.
As this project grows, we hope to see more and more collaborators. We want to encourage a culture of ownership, where people demonstrate ownership of various parts of the codebase - a file, a package, a subsystem. We should all try to respect each other's ownership, but we must not become territorial. Everyone should be ready to track an issue or feature across the code as needed.