How to contribute code
Contributions should start small and concrete. If you are unsure whether something fits, open an issue before a pull request.
- Focus on bug fixes, small improvements, or contained additions to existing projects.
- Prefer changes that are easy to test and reason about over large refactors or rewrites.
- Follow the existing coding style and patterns in the repository rather than introducing new abstractions.
- Use GitHub issues for discussion and pull requests for concrete changes. Keep descriptions factual and specific.
The primary home for code contributions today is the Skene GitHub organisation.
View Skene repositories on GitHubHow to propose experiments
Experiments are most useful when they are framed like small research projects, not feature requests.
- Describe the question you are trying to answer in one or two sentences.
- Outline the approach, constraints, and what a clear outcome would look like.
- Share results or learnings, even if the outcome is that the idea is not worth shipping.
Contribution boundaries
To keep the signal high, some types of input are explicitly out of scope for the community surface:
- Product support requests or debugging specific customer setups.
- Sales conversations, pricing negotiations, or procurement processes.
- Generic feature wishlists without a clear problem statement.
- Documentation that duplicates or competes with official guides.
Code of conduct
Contributions are expected to be professional, direct, and grounded in work. Disagreement is normal; disrespect is not. The short version is:
- Assume good intent, but do not require emotional labour from others.
- Critique ideas, not people.
- Keep conversations focused on the code, data, and decisions at hand.
A more detailed code of conduct will be linked here if and when it is formalised.