Documentation › User Guides › Organizations › Stage 5 › Contributing

Contributing to the Zyra community

Chapter 4 · about 8 minutes to read

You have read four stages of documentation and you are running production workloads on Zyra. You are now the kind of operator we learn the most from. This chapter is the short version of how to give back — and how to get a faster answer when something is wrong.

Time: about 8 minutes. Prerequisites: an organization account and at least one production deployment.

A note on honesty

Zyra is a small-team product. We read every bug report and feature request that comes in; we do not yet have a community team buffering us from operators. That has two consequences:

  • You will frequently get a response from someone who has touched the code in question. Use that.
  • We rely on you to make reports useful. A vague "it's broken" turns into a three-day email thread; a precise report with logs gets fixed faster than you expect.

How to file a useful bug report

Before you write anything, capture:

  1. What you did. Exact API call, dashboard click sequence, or CLI invocation. Redact secrets.
  2. What you expected. One sentence.
  3. What actually happened. Response code, error message, screenshot. Include the meta.request_id — that is how support traces the call end-to-end.
  4. Versions. Web dashboard build (page footer), backend version (GET /api/v1/health), and agent version (Settings → Devices → device row).
  5. Logs. From the dashboard error if available; from the Compute Node agent log path; from your VS container's stdout if the bug is in your workload's interaction with the platform.
  6. A minimal reproduction. Strip the report to the smallest case that still fails.

Email: hello@getzyra.io. Mark the subject [BUG] and we route it directly.

How to request a feature

The product roadmap is owned by the CPO and informed by what real operators ask for. To make your request count:

  • Lead with the problem, not the solution. "I cannot tell when a VS is approaching its cost budget" tells us more than "please add a cost_budget field."
  • Quantify the impact. "This costs my team ~3 hours per week to work around" is actionable; "nice to have" is not.
  • Propose the smallest version that would help. Often we ship that this sprint, then iterate.

Email: hello@getzyra.io, subject prefix [FEATURE].

Sharing patterns in the community

[VERIFY: dedicated community platform (Discord / Discourse / GitHub Discussions) — founder decision pending; link will be published on the documentation index page when it lands]

When the channel opens, contributions that punch above their weight:

  • Architecture write-ups. "Here is how we fan out a 50-shard ML batch on Zyra, what we tried first, what works now."
  • Cost tuning case studies. Before / after numbers, what we changed, the surprise that saved 30%.
  • Failure post-mortems. What broke, how you noticed, what you did, what you would do differently.
  • Tools you wrote. CI snippets, Terraform modules, dashboards, helper scripts.

We will boost the best of these on our blog (with your permission) and may invite you to write a longer case study. Email hello@getzyra.io if a case study sounds interesting — we provide editorial support and can offer credits, conference passes, or co-marketing depending on scope.

Security disclosures

Security issues do not go through the normal channels.

  • Email security@getzyra.io with details. We respond within one business day.
  • See /.well-known/security.txt for the canonical contact info.
  • Do not post security issues on any community channel before we have responded — coordinated disclosure protects every operator.

Out of scope: missing rate limits on landing-page forms, theoretical attacks requiring already-compromised credentials, and anything covered by the Security page as a known accepted trade-off.

Open-source status

The Compute Node agent and selected client libraries are tracked for open-source release. [VERIFY: public-repo status — founder issue pending; the strategy in docs/plans/documentation-strategy-2026-05-21.md outlines the hybrid model that does not block public release]

When the public repo flips:

  • Agent code will live at a public GitHub org.
  • Agent bug reports will move to GitHub Issues there.
  • A CONTRIBUTING.md will document the patch workflow.
  • Backend code remains source-available for security-conscious reviewers under NDA, not openly public for MVP1.

Brand and talks

If you are giving a talk, writing a blog post, or running a webinar that features Zyra:

  • The Zyra brand kit is available on request — email hello@getzyra.io.
  • We can review draft slides for technical accuracy, free of charge, with no edit veto.
  • Tagging us on social (@getzyra [VERIFY: official handle confirmation]) gets you a like and often a reshare.
  • Customer-named case studies require a written one-pager sign-off — we do not publish customer names without it.

What just happened

You finished the Organization Guide. You know the architecture patterns, the capacity planning method, the cost discipline, and the channels for giving back. The team would now like to hear from you.

Where to next

  • Email us with the thing you most wish worked differently.
  • Try the API reference (auto-generated, lives at the same URL as the dashboard).
  • Re-read Stage 1 — Sign up and think about which paragraph would have saved your past self the most time. Tell us — that is the next thing we improve.

Troubleshooting

  • No response in 2 business days. Re-send with subject prefix [NUDGE]. Check your spam folder.
  • Reply asks for information I cannot share. Tell us what you can share. We have NDAs available for the harder cases.
  • I think the bug is in my code, not Zyra's. Send it anyway — narrowing the divide is faster with two pairs of eyes.

Last reviewed: 2026-05-21