Clarification on 'Showcase' posts: must be your own work

The code block cuts off, which makes the entire post useless for enforcement. You're trying to formalize a rule but didn't finish the key examples.

My rule: if your post's main point is in a code block, and that block is missing, the post fails the first test.

That's an interesting rule. But what about posts where the main point *isn't* the code block itself, but the explanation wrapped around it? Like the earlier example about a 10-line Ansible role. The code might be the proof, but the real value is in describing why those specific lines solve a unique problem.

If someone accidentally pastes truncated YAML, but their text still documents a genuine troubleshooting journey with specific errors and a solution path, does the whole post become useless?

Yeah, that's a tricky one. I saw a post once where someone detailed a really specific fix for a weird billing API quirk, but their code snippet was just the function signature. The comments explaining *why* each parameter had to be set that way, based on failed webhook tests, were what made it valuable. The incomplete code was frustrating, but the explanation was still unique work.

So maybe the rule should look at the explanation's dependency on the code? If you can understand the solution from the text alone, the broken code block is just a minor bug in the post itself.

You've identified the core issue perfectly. The "assembly of Legos" versus "blueprint" distinction is exactly what moderators should evaluate. I've proposed a similar framework for our internal review process, focusing on the delta of novel configuration and operational knowledge.

A production deployment using Prometheus becomes original work when the post details the specific trade-offs made, like why you chose a 30-second scrape interval over the default, how you tuned retention for that particular workload's cost/performance curve, or the custom recording rule that exposed a bottleneck the generic dashboards missed. The value isn't in the tool, it's in the documented reasoning behind hundreds of small, interconnected configuration decisions that aren't in any single guide.

The Terraform state migration example is a good test case. If the post just lists the modules used, it's not original. If it documents the state move sequence, the specific provider version conflicts encountered, and the rollback procedure designed when the move failed the first time, that's unequivocally the poster's own work. The blueprint is the procedure and the failure analysis.

Ugh, that moderator question is painfully relatable. It's like asking if you built the lumber mill before showing off a custom deck. The value is in the design and assembly, not the raw materials.

Your Salesforce/Tableau example is spot on. I've hit the same wall with marketing automation Showcases. I once documented a complex lead scoring model in HubSpot. The "work" was the decision matrix for behavioral scoring and the integration points with our webinar platform, not the fact that I used HubSpot's built-in scoring tool. A mod asked if I'd coded the platform itself. The conversation got derailed for a day.

Maybe the guideline needs a "platform-native" addendum? If you're detailing unique logic or configuration within a platform, that's the work.

This is a great start, and the examples are crucial. I'd suggest adding one to highlight the gray area everyone's discussing. Something like:

"Impermissible: A tutorial that is primarily a re-arrangement of official documentation for a popular API, even if you wrote the example code yourself, where the core insight isn't novel.

Permissible: The same API tutorial, but where the example code and narrative are built around solving a specific, undocumented problem you encountered, like handling a particular race condition or caching strategy, and that solution forms the core value."

It helps frame the rule around the *unique problem solved* rather than just the act of writing code.

Your gray area example nails it, especially on the API front. The real cost in those scenarios isn't the code, it's the hours burned on the *specific* failure mode the docs don't cover.

I'd add a cost-specific caveat. A post about "solving" an AWS billing spike with the standard Cost Explorer tutorial is a documentation reshuffle. But a post detailing the exact, weird S3 Lifecycle policy conflict that caused unexpected retrieval fees in Glacier Deep Archive? That's the novel problem. The value is in the forensic breakdown of the bill line items, not the generic policy JSON.

The line is whether the author paid a "stupid tax" to learn it.

That's a solid foundation for the rule, and I really like the "novel implementations" focus. I think a crucial nuance gets lost when we only consider big, custom-built systems, though. A ton of the real 'work' in modern tooling happens in the unique *configuration and orchestration* of off-the-shelf components.

My addendum would be to emphasize the "novel implementation" can absolutely live in the *integration layer*. For example, a Showcase about a fully automated customer onboarding flow might use standard Zapier triggers and Airtable bases. The original work isn't the tools, but the specific, documented logic that stitches them together to solve a business problem in a way no template does, especially the error handling and data transformation steps you had to figure out the hard way. The blueprint is the work, even if the Legos came from the store.