Thank you for contributing to Rafiki 🎉 Your contributions are essential to making this project better.
- Have you read the code of conduct?
- Check out the existing issues & see if we accept contributions for your type of issue.
You can contribute to Rafiki in several ways.
Discussions are where we have conversations about Rafiki.
If you would like to discuss topics about the broader ecosystem, have a new idea, or want to show off your work - join us in discussions.
We use GitHub issues to track feature requests. If there is something that you would like to see implemented in Rafiki, open an issue using the "Feature or Feature Subtask" template. Please make sure you check whether the feature has already been requested by searching existing open issues first before opening a new one.
We use GitHub issues to track tasks that contributors can help with. We haven't finalized labels yet for contributors to tackle. If you want to help with work related to an issue, please comment on the issue before starting work on it.
If you've found something that needs fixing, search open issues to see if someone else has reported the same thing. If it's something new, open an issue. We'll use the issue to discuss the problem you want to fix.
Feel free to fork and create a pull request on changes you think you can contribute.
The team will review your pull request as soon as possible.
We started to maintain public-facing documentation for Rafiki on rafiki.dev. The project is new, and available documentation there is scarce. We'd love help to fill that out. A list of issues is available.
This project uses pnpm. A list of steps for setting up a local development environment can be found in the Readme.
DO NOT use
npm install
. This will cause the project to spontaneously self-destruct 💥
We use labels to communicate the intention of issues and PRs.
discussions:
prefix denotes issues that can be converted to discussions.good first issue
are great issues for newcomers to take on.pkg:
prefix denotes issues/PRs related to a specific package.team:
prefix lets contributors know if the issue will be done by the core team or not.triage
issues that the core team needs to assign labels to.type:
prefix denotes a specific action/category to issues/PRs.
Some labels will be automatically assigned to PRs.
All the code quality tools used in the project are installed and configured at the root. This allows for consistency across the monorepo. Allows new packages to be added with minimal configuration overhead.
We try not to put config files in workspaces, unless absolutely necessary.
Eslint is used for linting.
./.eslintrc.yml # config
./.eslintignore # ignore file
Eslint config should not be overridden in any packages.
Prettier is used for formatting.
./.prettierrc.yml # config
./.prettierignore # ignore file
Prettier config should not be overridden in any packages.
GraphQL Code Generator is used for generating TypeScript types from schema.graphql
files.
./<package>/codegen.yml # GraphQL Code Generator config
The generate
script should be run if a package's schema.graphql
file is modified.
pnpm --filter <package> generate
Jest is used for testing.
./jest.config.js # config used to configure projects and run all tests
./jest.config.base.js # (base jest config, imported by other packages)
./packages/*/jest.config.js # jest config file for package * (extends base.config.base.js)
Jest config at the root is intended to be a base config that should be extended by each package to suit the package's testing requirements.
Husky provides git hooks.
./.husky/commit-msg # linting commit messages
./.husky/pre-commit # perform functions before committing
Commitlint is used for linting commit messages so that they conform to conventional commits.
./commitlint.config.js # config
Lint-staged is used for linting and formatting staged files on commit.
./.lintstagedrc.yml # config
Typescript is the chosen language.
./tsconfig.json # config
Typescript config at the root is intended to be a base config that should be extended by each package to suit the package's requirements.
We use GitHub actions to manage our CI pipeline.
The workflows can be found in .github/workflows
If you encounter any issues or have a feature request, please create a new issue and provide the following details:
- A clear and descriptive title.
- A detailed description of the issue, including steps to reproduce if applicable.
- Information about your environment (e.g., operating system, browser, version).
- Any relevant screenshots or error messages.
- Fork the repository.
- Create a new branch from
main
. - Make your changes and commit them.
- Create a pull request (PR) to
main
. - Ensure your PR includes a clear title and description following the Conventional Commits Specification.
- If your PR addresses an issue, reference the issue in the description using
Closes #123
. - Be patient and be prepared to address feedback and make changes if needed.
- Project maintainers will review your PR for code quality, correctness, and adherence to guidelines.
- Please respond to any feedback promptly and make necessary changes.
- Once the PR is approved, it will be merged into the main branch.
Thank you for contributing to Rafiki! We appreciate your time and effort in helping make Rafiki better. Join our community on Slack to connect with other contributors and stay updated on project developments.
Happy coding!