Skip to main content
Thank you for showing an interest in contributing to Plane! All kinds of contributions are valuable to us. This guide will help you quickly onboard and make your first contribution.

Ways to Contribute

There are many ways you can contribute to Plane:
  • Try Plane Cloud and self-hosting and provide feedback
  • Add new integrations
  • Add or update translations
  • Help with open issues or create your own
  • Share your thoughts and suggestions
  • Help create tutorials and blog posts
  • Request features by submitting proposals
  • Report bugs
  • Improve documentation - fix incomplete or missing docs, bad wording, examples, or explanations

Before You Start

Search Existing Issues

Before submitting a new issue, search the issues tab. An issue or discussion might already exist that can inform you of workarounds or provide new information.

Set Up Your Development Environment

Make sure you have your local development environment configured before contributing code.

Submitting Issues

Creating Quality Bug Reports

When reporting a bug, provide us with a minimal reproduction scenario. This helps us investigate without asking follow-up questions:
  • Third-party libraries being used and their versions
  • A specific use case that fails
  • Steps to reproduce the issue
  • Expected vs. actual behavior
You can use a repository or Gist to provide a reproducible example.
Without a minimal reproduction, we may not be able to investigate or resolve the issue.

Naming Conventions for Issues

Use clear and concise titles following this format:
  • Bugs: 🐛 Bug: [short description]
  • Features: 🚀 Feature: [short description]
  • Improvements: 🛠️ Improvement: [short description]
  • Documentation: 📘 Docs: [short description]
Examples:
  • 🐛 Bug: API token expiry time not saving correctly
  • 📘 Docs: Clarify RAM requirement for local setup
  • 🚀 Feature: Allow custom time selection for token expiration
This helps us triage and manage issues more efficiently. Open a new issue

Feature Requests

If you’d like to request a new feature:
  1. Submit a feature request
  2. If you want to implement it yourself, submit an issue with your proposal first to ensure alignment with project goals
  3. Follow the coding guidelines below

Coding Guidelines

To ensure consistency throughout the source code, follow these rules:

Code Style

  • TypeScript: Strict mode enabled, all files must be typed
  • Naming Conventions:
    • camelCase for variables and functions
    • PascalCase for components and types
  • Imports:
    • Use workspace:* for internal packages
    • Use catalog: for external dependencies

Linting and Formatting

Plane uses OxLint and oxfmt for code quality:
pnpm check:format
Configuration files:
  • .oxlintrc.json - Linting rules
  • .oxfmtrc.json - Formatting rules

Testing

  • All features or bug fixes must be tested by one or more specs (unit tests)
  • Use the existing test framework for each package
  • Run tests before submitting your pull request

Error Handling

  • Use try-catch blocks with proper error types
  • Log errors appropriately using the logger package
  • Provide meaningful error messages

State Management

  • MobX stores should be placed in packages/shared-state
  • Follow reactive patterns
  • Use observables, computed values, and actions appropriately

Component Development

  • Build reusable components in @plane/ui
  • Use Storybook for isolated development and testing
  • Start Storybook: pnpm --filter=@plane/ui storybook

Contributing Translations

Translation Structure

Translations are organized by language in the packages/i18n/src/locales/ directory:
packages/i18n/src/locales/
    ├── en/
    │   ├── core.json       # Critical translations
    │   └── translations.json
    ├── fr/
    │   └── translations.json
    └── [language]/
        └── translations.json

Translation Format

Plane uses IntlMessageFormat for dynamic content: Simple variables:
{
  "greeting": "Hello, {name}!"
}
Pluralization:
{
  "items": "{count, plural, one {Work item} other {Work items}}"
}

Updating Translations

  1. Locate the key in locales/<language>/translations.json
  2. Update the value while keeping the key structure intact
  3. Preserve any existing ICU formats (variables, pluralization)

Adding New Translation Keys

  1. Add the key to all language files
  2. Use English as a placeholder if translations aren’t immediately available
  3. Keep the nesting structure consistent across all languages
  4. Apply ICU format uniformly if using dynamic content

Adding New Languages

1

Update type definitions

packages/i18n/src/types/language.ts
export type TLanguage = "en" | "fr" | "your-lang";
2

Add language configuration

packages/i18n/src/constants/language.ts
export const SUPPORTED_LANGUAGES: ILanguageOption[] = [
  { label: "English", value: "en" },
  { label: "Your Language", value: "your-lang" },
];
3

Create translation files

  1. Create locales/your-lang/ folder
  2. Add translations.json file
  3. Copy structure from an existing translation file
4

Update import logic

private importLanguageFile(language: TLanguage): Promise<any> {
  switch (language) {
    case "your-lang":
      return import("../locales/your-lang/translations.json");
    // ...
  }
}

Translation Quality Checklist

Before submitting:
  • All translation keys exist in every language file
  • Nested structures match across all languages
  • ICU message formats are correctly implemented
  • All languages load without errors
  • Dynamic values and pluralization work as expected
  • No missing or untranslated keys

Pull Request Process

  1. Fork the repository and create your branch from master
  2. Make your changes following the coding guidelines
  3. Test your changes thoroughly
  4. Run checks: pnpm check to ensure code quality
  5. Commit your changes with a clear commit message
  6. Push to your fork and submit a pull request
  7. Wait for review - maintainers will review your PR and provide feedback

Pull Request Guidelines

  • Provide a clear description of the changes
  • Reference any related issues
  • Include screenshots for UI changes
  • Ensure all checks pass
  • Be responsive to feedback

Getting Help

Questions, suggestions, and thoughts are always welcome! We follow a Code of Conduct in all our community channels.

Next Steps

Happy contributing! 🌍✨

Build docs developers (and LLMs) love