Skip to content

Latest commit

 

History

History
163 lines (108 loc) · 8.87 KB

CONTRIBUTING.md

File metadata and controls

163 lines (108 loc) · 8.87 KB

Contributing to Devopness

Thank you for considering contributing to Devopness! We appreciate your help and value all community contributions.

Before getting started

Show your appreciation for Devopness 💜! It means a lot to our team:

Code of Conduct

Please make sure to read and observe our Contributor Code of Conduct.

Contributing Guidelines

Getting Started

Fork & Setup Workflow:

  1. To become familiar with working with forks, please read and follow the standard fork based workflow, which could be summarized with the following steps:

Ways to Contribute:

  1. Report a bug 🐛 or submit new ideas 🆕 💡
    • ❓ Ask questions and help other Devopness users with open discussions
  2. Find a Good First Issue
    • Good first issues are a great way to start contributing to the project and get familiar with the codebase. Browse the list and choose an issue that interests you!

Submitting a Pull Request

  1. Open a pull request: Once you've implemented a new feature or fix, open a pull request for review
  2. Review your own PR first: Take a moment to review your own changes:
    • Ensure all automated checks are passing
    • Verify code quality and adherence to best practices
    • Check that all files end with a final newline (this is important!)
    • Make sure you have properly configured git or your IDE (see IDE Configuration below) to automatically add final newlines
      • 💡 Tip: IDE configuration is easier than git configuration 🥭 🍒
  3. Ask for review:
  4. Merge: Once approved, maintainers will merge your pull request into the main repository branch

IDE Configuration

To ensure consistent code formatting and avoid common issues, please configure your IDE with these settings:

For VSCode, Cursor, Windsurf, and similar editors:

Add these settings to your workspace or user settings (settings.json):

{
  "files.insertFinalNewline": true,
  "files.trimFinalNewlines": true
}

This ensures:

  • All files end with a final newline (prevents "No newline at end of file" warnings)
  • Trailing newlines are trimmed (keeps files clean)

Why this matters: Consistent file endings make diffs cleaner, prevent merge conflicts, and follow POSIX standards. It's a small detail that makes a big difference in collaborative development!

Pull request titles

Pull request titles should:

  • be written in the active imperative form
  • not end with a period (.)
  • be read in natural language. As a simple rule, one can pretend the message in a pull request title starts with "This change will ..."
    • Example: for a pull request that has the title fix broken links on user profile page, it could be read as This change will ... fix broken links on user profile page

Here are some bad examples of pull request titles we're trying to avoid:

  • Fixes a bug
  • Adds a feature
  • Feature now does something

Pull request descriptions

A good PR description is essential - even for DRAFT pull requests! It helps reviewers understand your changes quickly and provides context for future reference.

What to include:

  • Clear summary: What does this PR do? Why is it needed?
  • Visual evidence (when applicable): For changes that affect UI, documentation, or visual elements, include BEFORE and AFTER screenshots or examples
    • This is especially important for design system changes, documentation updates, or any visual modifications
    • Show that images are rendering correctly, layouts work as expected, etc.
  • Testing notes: How did you test this? What scenarios did you cover?
  • Related issues: Link to any related issues or discussions

Examples of great PR descriptions:

Remember: Even if your PR is a work in progress (DRAFT), a good description helps maintainers understand your direction and provide early feedback!

Feature Work

When to open an issue first:

  • For larger features or breaking changes, please open a new issue before investing a lot of your time, so we can discuss and plan the feature together.
  • Please browse current issues to make sure your issue is unique, to lighten the triage burden on our maintainers.

For smaller features: Feel free to submit a PR directly, but please limit your pull requests to contain only one feature at a time. Separating feature work into individual pull requests helps speed up code review and reduces the barrier to merge.

Releases

We publish package releases and changelogs using GitHub Releases together with Changesets.

Changesets

TL;DR: If your changes affect packages, you'll need to add a changeset file. This helps us generate changelogs and version packages correctly.

Changesets are small files that describe what changed and what kind of version bump is required (patch, minor, or major). They are used to generate changelogs and help our release tooling determine new package versions.

  • Why: ensures consistent, readable changelogs and predictable versioning.
  • Where: changeset files live under the repository root in the .changeset/ directory.

Read the official Changesets documentation: Changesets

Adding a changeset

Preferred (interactive): run the CLI from the repo root and follow the prompts:

npx @changesets/cli

This interactive command will ask which packages are affected, what type of bump is required, and for a short description. It will create a new file under .changeset/ which must be included in your Pull Request.

Manual: you can also create a markdown file directly in .changeset/. See the docs for the exact file format and examples: Adding a changeset

Pull Request checklist for changes that affect packages

  • Include a changeset: make sure the generated or manual changeset file is in your branch and PR.
  • Accurate bump type: confirm the chosen bump (patch/minor/major) matches the user-visible change.
  • Run tests & linters: ensure CI passes before requesting a merge.
  • Ask if unsure: if you’re unsure what bump to choose, add a note in the PR or start a discussion so maintainers can advise.

If you need help creating a changeset or understanding bump types, start a discussion or mention maintainers on your pull request.

Getting Help

Need help? Have questions? Want to connect with other contributors? Join us on Discord or start a GitHub discussion!