NimbusAPI

Contributing

How contributions work and what to expect as a contributor or maintainer

Thanks for your interest in Nimbus! This document outlines how contributions work and sets clear expectations for maintainers and contributors.

Quick Navigation

Philosophy

Nimbus is maintained by volunteers who use it in production systems. We want to keep the library useful, stable, and maintainable. That means being thoughtful about what goes into the codebase and protecting maintainer time so we can keep doing this long-term.

Reporting Bugs

Bug reports are welcome! Good bug reports help everyone.

Before opening an issue:

  • Check if it’s already been reported
  • Try to reproduce it with the latest version
  • Check Discussions in case it’s a usage question

A good bug report includes:

  • Nimbus version
  • .NET version and runtime
  • Clear steps to reproduce
  • What you expected to happen
  • What actually happened
  • Relevant code snippets or stack traces

We’ll likely close issues that:

  • Are actually questions (please use Discussions)
  • Don’t include reproduction steps
  • Can’t be reproduced
  • Are stale (no activity for 60+ days)

Feature Requests

We love hearing ideas! But implementation bandwidth is limited.

Process:

  1. Open a Discussion in the “Feature Requests” category
  2. Describe your use case and why existing functionality doesn’t work
  3. Wait for maintainer feedback before writing code
  4. If approved, we’ll create an issue to track implementation

We’ll reject features that:

  • Significantly increase complexity for edge cases
  • Break existing APIs without compelling reason
  • Are better suited as external packages
  • Don’t align with Nimbus’s core mission

Unsolicited feature PRs (without prior discussion) will be closed politely. We know this feels harsh after you’ve invested time, but it protects both you and us from wasted effort.

Pull Requests

Bug Fixes

Small, focused bug fixes are welcome as PRs!

Requirements:

  • Tests that demonstrate the bug and verify the fix
  • Clear description of what was broken
  • No unrelated changes
  • Follow existing code style

Features

Only submit feature PRs after the feature has been discussed and approved (see above).

What We’re Looking For

  • Clean, readable code
  • Appropriate test coverage
  • No breaking changes without discussion
  • Minimal scope — one thing per PR

Review Process

Maintainers respond when time permits. We’re doing this in our spare time, so reviews might take a while. If you haven’t heard back in two weeks, a gentle ping is fine.

Code of Conduct

Basic rule: Be respectful.

We have zero tolerance for:

  • Demands on maintainer time
  • Entitled behavior
  • Harassment or abuse

Issues or PRs with inappropriate behavior will be closed without discussion.

Commercial Support

Nimbus is provided as-is under [LICENSE]. Community support is best-effort when maintainers have time.

If you need:

  • Guaranteed response times
  • Implementation assistance beyond basic usage
  • Architecture review for your specific use case
  • Custom feature development
  • Training or workshops

Let’s talk about a consulting arrangement: [your contact method]

Many companies get great value from Nimbus — paying for dedicated support time helps sustain the project and gets you the help you need.

Support Boundaries

Free community support (best effort):

  • Bug reports via Issues
  • General questions via Discussions
  • Documentation improvements

Paid consulting:

  • Everything else that requires significant maintainer time
  • If you’re stuck on implementation and need hands-on help
  • If your company relies on Nimbus and needs dedicated support

This isn’t about being unfriendly — it’s about sustainability. We want to keep Nimbus healthy for years to come.

Questions?

Start a Discussion. We’re friendly, just bounded.

Nimbus is maintained by volunteers who use it in production. We share it because we think it’s useful. We’re happy to help where we can, but this is not a commercial support contract.