Create Write for Percona community (#1193)

blog article for community writing

Co-authored-by: Daniil Bazhenov <daniil.bazhenov@percona.com>

Author: lauraczajkowski

content/blog/2026/Write for Percona community

@@ -0,0 +1,97 @@
+date: "2026-05-22"
+tags: ['Community', 'Percona', 'Open Source', 'Events']
+categories: ['Community']
+authors:
+  - laura_czajkowski
+images:
+  - 
+slug: write-for-percona-community
+
+# Write for the Percona Community
+
+You've fixed something gnarly in production this year. You've migrated a database that nobody wanted to touch. You've built something on top of Percona Operators, or Percona Toolkit, or Percona Monitoring and Management (PMM), and you've learned things along the way that aren't written down anywhere yet.
+
+Write it up. We'll publish it, and we'll pay you.
+
+## What we're doing
+
+The Percona Community Writers Program publishes technical posts from the people actually using these tools — DBAs, developers, contributors, and engineers running real workloads. Posts go up on [percona.community/blog](https://percona.community/blog) under your name, with your bio and links.
+
+For every post we publish, you get:
+
+- **$350** paid out after publication
+- **Community engagement points** you can redeem in our swag store for t-shirts, stickers, and other items
+
+The points stack across contributions. The more you write, the more you collect.
+
+#### A note on payment
+
+*Not everyone can accept payment for writing — employment contracts, tax situations, visa rules, and conflict-of-interest policies all get in the way. If that's you, we'll donate the same $350 to an open source project or community of your choice on your behalf. Tell us who to send it to when you pitch.*
+
+## What we want to read
+
+Anything you've done with the Percona stack — or alongside it — that another engineer would learn from. Some directions to consider:
+
+- **Percona Operators** — running databases on Kubernetes, scaling decisions, upgrade paths, what surprised you
+- **Percona Toolkit** — how you use specific tools in your day-to-day, scripts you've built around them, edge cases
+- **Migrations** — moving between versions, between database engines, on-premises to cloud, the parts that aren't in the docs
+- **Troubleshooting** — a real incident, what you saw, what fixed it, what you'd do differently
+- **Percona Monitoring and Management (PMM)** — dashboards you've built, alerts that actually catch things, integrations
+- **Databases themselves** — MySQL, PostgreSQL, MongoDB, MariaDB, Valkey, anything in the open source database world you're hands-on with
+
+We're not only interested in Percona-product posts. If you're active in the wider open source database community — contributing to MySQL, PostgreSQL, Valkey, or anywhere else — we want to hear about that work too. Your projects, your perspective, your hard-won opinions.
+
+## Standards
+
+Every submission is reviewed by the community team for technical accuracy and grammar before it goes live. We're not gatekeeping — we're making sure your name goes on something solid.
+
+One firm rule: **no AI-generated content**. We run every submission through [GPTZero](https://gptzero.me/) and it has to come back clean. We're publishing your voice and your experience, not a model's summary of either. If you used AI to help draft, that's fine — but the post needs to read as yours and pass the check.
+
+## How to start
+
+Pitch us first. A couple of sentences on what you want to write about and why you're the person to write it is enough. We'll reply with feedback, a timeline, and any direction that helps you write a stronger post.
+
+You don't need to be a published writer. You need to have done something and be willing to explain how. A 900-word post about how you debugged a replication lag issue last quarter is more valuable than a 3,000-word survey of the database landscape.
+
+Send pitches and questions to the Percona Community team — by filling in **this form**.
+
+### Open topics: blog, talks, guides
+
+Not sure where to start? Here are some directions we'd love to see covered. Pick one, narrow it down to something you've actually done, and pitch us.
+
+**Databases**
+
+- Automating database setup for production in under a few hours
+- Backup and disaster recovery strategies that hold up
+- Failure stories — what broke, what you learned
+
+**DevOps and reliability**
+
+- Database Reliability Engineering (DBRE) in practice
+- Site Reliability Engineering (SRE) applied to databases
+- Monitoring and SLAs that mean something
+- Useful scripts you actually run in production
+- Testing and QA for database changes
+
+**Distributed computing**
+
+- Consensus algorithms and real-world implementations
+- Synchronous vs asynchronous replication — trade-offs and where each fits
+
+**How-tos**
+
+- Moving from a single node to a cluster (any DB engine)
+- Batch processing patterns
+- Stream processing patterns
+- Metrics that actually tell you something
+
+**Open source**
+
+- Measuring your open source project's success
+- Bug squashing done right
+- Licensing — what to know before you pick one
+- Vendor lock-in and how to spot it early
+
+---
+
+We pay engineers to share what they've learned. That's the whole offer. If you've got something worth writing, write it.