Embark Contributor Guidelines
Welcome! This project is created by the team at Embark Studios. We're glad you're interested in contributing! We welcome contributions from people of all backgrounds who are interested in making great software with us.
At Embark, we aspire to empower everyone to create interactive experiences. To do this, we're exploring and pushing the boundaries of new technologies, and sharing our learnings with the open source community.
If you have ideas for collaboration, email us at email@example.com.
We're also hiring full-time engineers to work with us in Stockholm! Check out our current job postings here.
If you have ideas or how to improve our projects, you can suggest features by opening a GitHub issue. Make sure to include details about the feature or change, and describe any uses cases it would enable.
Feature requests will be tagged as
enhancement and their status will be updated in the comments of the issue.
When reporting a bug or unexpected behaviour in a project, make sure your issue describes steps to reproduce the behaviour, including the platform you were using, what steps you took, and any error messages.
Reproducible bugs will be tagged as
bug and their status will be updated in the comments of the issue.
Issues will be closed and tagged as
wontfix if we decide that we do not wish to implement it, usually due to being misaligned with the project vision or out of scope. We will comment on the issue with more detailed reasoning.
The labels for this repository are divided into the following categories;
c:Crate Issues specific a single crate in the repository.
g:GPU Issues specific a GPU vendor.
p:Platform Issues specific a single operating system or platform.
s:Status The current status of a PR or issue.
t:Type The general type of the issue. (E.g.
t: bugfor bugs.)
If you're ready to contribute, start by looking at our open issues tagged as
help wanted or
good first issue.
You can comment on the issue to let others know you're interested in working on it or to ask questions.
Major Change Process
Most bug fixes can be implemented directly by opening a PR, however for larger design decisions and major changes to the compiler's architecture, this repository uses a two stage "Major Change Proposal" and "Request For Comments" process. If you're unsure about what's required for a specific change you should always start with opening an issue or asking the team over on the
#rust-gpu channel in the Embark Discord.
Major Change Proposal (MCP)
A proposal to make a significant internal changes or small public facing changes to the compiler. An MCP is opened as an issue on
rust-gpu the repository. An MCP typically only requires one member's approval. Though if the change is significantly big enough it may require the full team's sign off or require an RFC.
An MCP should generally be a short (1-2 paragraphs) high level overview of the change you would want to make, the motivation behind the change, and potential solutions. There is a major change issue template you can use for convenience.
Examples of what would require an MCP:
- Changing the compiler architecture.
- Adding support for an existing Rust language or feature.
- Small additions (e.g. new methods) to
- Proposing an RFC.
Examples of what would not require an MCP:
- Updating documentation
- Fixing existing bugs
- Performance improvements
Request For Comments (RFC)
A proposal to make significant public facing changes to the compiler or standard library. RFCs are opened as pull requests to the
rust-gpu repository. RFCs require full sign off by the team, before being approved or implemented. Check out the RFC
000-template.md document for details on the structure.
Examples of what would require an RFC:
- Major additions to
spirv-std, such as new APIs, or breaking changes to existing ones.
- You file a major change proposal outlining the changes and the motivation for it.
- A member of the team will review the proposal and tag it with the appropriate label.
mcp: acceptedmeans that the MCP has been accepted and is ready for a pull request implementing it. 2.2.
mcp: rfc neededmeans that the MCP has been accepted as something the team would like but needs a full RFC before the implementation. 2.3 Closing an issue means that the MCP has rejected.
- If the proposal has been accepted then the implementation can begin.
Pull Request Process
- Fork the repository.
- Create a new feature branch.
- Make your changes. Ensure that there are no build errors by running the project with your changes locally.
- Open a pull request with a name and description of what you did. You can read more about working with pull requests on GitHub here.
- A maintainer will review your pull request and may ask you to make changes.
You can read about our standards and recommendations for working with Rust here.
Unless otherwise specified, all Embark open source projects are licensed under a dual MIT OR Apache-2.0 license, allowing licensees to chose either at their option. You can read more in each project's respective README.
Code of Conduct
Please note that our projects are released with a Contributor Code of Conduct to ensure that they are welcoming places for everyone to contribute. By participating in any Embark open source project, you agree to abide by these terms.