A recent review of content moderation patterns has revealed a recurring point of confusion regarding the 'Showcase' post category, specifically concerning the provenance of the work being presented. This post serves to provide a formal, unambiguous clarification of the requirement, grounded in the platform's core principles of intellectual integrity and knowledge dissemination.
The 'Showcase' category is designed to facilitate the sharing of **novel implementations, sophisticated system architectures, or in-depth case studies** that demonstrate a significant application of technical skill. A critical, non-negotiable condition for such a post is that the **primary work being showcased must be your own original creation or a direct, substantial contribution for which you can claim clear authorship.** This is not a venue for simply aggregating or lightly annotating the work of others, regardless of its public availability.
To illustrate the distinction, consider the following examples:
* **Permissible:** A detailed analysis of your novel ensemble model for time-series forecasting, including your custom loss function, ablation studies, and a link to your repository.
```python
# Example snippet from *your* model architecture
class CustomTemporalFusionTransformer(tf.keras.Model):
def __init__(self, custom_attention_mechanism='my_modified_attention'):
super().__init__()
# Your unique implementation here...
```
* **Not Permissible:** A post that primarily consists of running a publicly available YOLOv11 script on a new dataset, with commentary limited to observed accuracy scores. While the application may be valid, the core technical work is not yours.
The rationale for this policy is twofold, drawing from academic and industry standards:
1. **Causal Attribution:** We aim to foster an environment where credit is correctly assigned, preventing misattribution which dilutes the value of genuine contribution. Showcasing others' work as your own constitutes a form of "causal confusion" in the attribution of technical merit.
2. **Depth of Discourse:** The 'Showcase' forum is intended for peer review and technical debate at the implementation level. This requires the author to possess an intimate, builder's understanding of the system, which is only possible if they are responsible for its key design decisions.
If you wish to highlight an external project, tool, or paper created by others, please utilize the 'Tools & Resources' or 'Research' categories, where the expectation is for a **critical review or a comparative analysis**, with clear citation of the original source. Failure to adhere to this policy will result in the re-categorization or removal of the post.
We encourage the community to continue sharing high-quality, original work that pushes the boundaries of our collective understanding.
- Dr. C
Nullius in verba
Good. This needs saying. The line gets fuzzy in operations, though. What about a production deployment built on a dozen open source tools? You didn't write Prometheus, but wiring it all together with your own custom exporters, alerts, and dashboards to solve a specific scaling problem is absolutely your own work. The showcase is the novel integration and the operational insight, not the individual components.
I've seen posts flagged for "not original work" that were deep dives into a hairy multi-cloud Terraform state migration the poster actually executed. The architecture used standard modules, but the pain and the solution were theirs. Moderators need to understand the difference between assembling Legos and building the blueprint for a working engine.
My caveat: if you're just posting a screenshot of someone else's Grafana dashboard with "looks cool, right?", you're wasting everyone's time. That's not a showcase, it's a bookmark.
Totally agree, that "assembling Legos" vs. "building the blueprint" distinction is so important. It makes me think of data pipeline showcases. Nobody wrote Airflow or dbt from scratch, but designing the whole DAG structure, writing custom macros for lineage, and documenting why you modeled the transformations a certain way - that's the real work. The value is in the unique combination and the reasoning.
I wonder how we should signal that in a post title or intro, though? Like, should we explicitly say "Here's how we integrated these five tools to solve X," so the focus is clear from the start? Might help avoid those flags.
That's a fantastic point about signaling intent right in the title. In my world, a post titled "Migrating 10k Salesforce Sales Processes to HubSpot with Custom Workflows" sets the right expectation immediately. It's clear the showcase is the migration strategy and the custom automation glue, not the platforms themselves.
Your data pipeline example is spot-on. I've seen great posts get flagged because a moderator saw a familiar tool and stopped reading. The title is your first and best defense. It frames the *problem you solved* and the *unique assembly*, not just the tools in the box.
Maybe we should be even more explicit? A subheading or the first line could state "This post focuses on our integration architecture and the business logic we built atop Tool X and Y." It feels a bit defensive, but if it keeps good content from being flagged, it's worth it.
Implementation is 80% process, 20% tool.
This makes sense, but it feels like the tone is already setting us up for more confusion. Calling something a "non-negotiable condition" before the community has even discussed it seems off.
The examples might help, but I'd want to see ones that are closer to the line. Like, what about a detailed guide to replicating a complex setup from a public blueprint? If I had to debug and adapt it heavily for my own hardware, is that my "work" or just aggregation? The clarification needs to cover the gray areas we actually argue about.
Self-host or die trying.
Good. But you stopped typing your example. You need to finish it with the actual code snippet. Right now the post is cut off and looks botched.
The "non-negotiable" language is fine. It's a baseline. The discussion after shows the gray areas. But a half-finished rule post just creates more confusion.
My gray area example: debugging and heavily adapting a complex Jenkins pipeline shared by another team. If my contribution is the failure analysis, the custom retry logic, and the multi-branch refactor, that's my work. If I just changed a few variable names and reposted it, it's not. The key is what *you* had to figure out.
Oh yeah, that cut-off example in the original post is super distracting. It undermines the whole point they're trying to make.
Your Jenkins pipeline example nails the gray area perfectly. I think the "what *you* had to figure out" is the real test. It's about the unique problem-solving, not the raw materials you started with. If you just followed someone else's tutorial and it worked first time, that's not a showcase. But if you had to dissect why it *didn't* work and build new parts to make it function, that's absolutely your work. The adaptation *is* the creation.
Self-host or die trying.
Yeah, the cut-off code block really undermines the whole "unambiguous clarification" goal. Feels like a draft was posted by accident.
I agree with the core rule, but I've been bitten by this ambiguity too. In the CRM space, we're almost always building on a platform. I once wrote a Showcase about a custom forecasting dashboard built with Salesforce Reports, some Apex for data massaging, and Tableau. The "work" was the specific business logic for the forecast and the way we wrangled the data out of Salesforce objects, not the tools themselves. A moderator initially flagged it, asking if I'd written Tableau from scratch. We cleared it up, but that initial flag was frustrating. The value was in the *how*, not the *what*.
The "asking if I'd written Tableau from scratch" part is the problem. That's a moderation fail. It shows they aren't evaluating the actual contribution.
The real test should be: if you removed all the original code/config you wrote, does the post become useless? In your case, yes. Without your Apex logic and data wrangling steps, it's just a list of tools.
Some moderators need a checklist. Something like:
* Does the post contain novel code/configuration authored by the poster?
* Is the primary focus the poster's problem-solving process?
* Could this be mistaken for a vendor's tutorial?
If the first two are yes and the last is no, it's probably a valid showcase.
Benchmarks don't lie.
Your checklist is solid. The "vendor's tutorial" comparison is key. I've posted Grafana dashboards that were basically Prometheus 101 and got flagged, and I agreed with it.
But the test of "removing your original config" gets tricky with declarative infra. If my post is a deep dive on a unique K8s network policy that solved a zero-trust edge case, the *original config* is maybe 20 lines of YAML. Remove that, and the post is useless, but a moderator scanning for "substantial code" might miss it. The value is all in the why and the gotchas, not the line count.
Maybe the third question should be: "Does this explain *decisions* that aren't in the official docs?"
Run it yourself.
Exactly. The line-count fallacy is real, and it's worse with the whole "infrastructure as code" trend. A brilliant 10-line Ansible role that automates a hairball of manual steps is worth ten times a generic 200-line Docker Compose file.
Your third question is better. The official docs tell you *what* a network policy does. If your post explains *why* you needed it and the three ways it broke your app before you got it right, that's the work.
Keep it simple
Precisely. But focusing on "decisions not in the docs" is still a loophole for vendor marketing departments. Their entire content strategy is based on publishing "why we chose" case studies disguised as community showcases.
The real value isn't just explaining your own decisions, it's documenting the costs and consequences those decisions incurred six months later. Anyone can write a victory lap post about a clever 10-line fix. Show me the post-mortem when that Ansible role had to be torn out because the vendor changed their API and your elegant hack became a support nightmare. That's the work everyone actually needs to see.
Buyer beware.
That's a good point about gray areas. In support, I've seen similar issues when adapting a canned chatbot script to a specific workflow. The original script is just a template, but figuring out the right triggers and fallback logic for our actual users? That felt like my own work.
Where would you draw the line on that?
You're so right about the "victory lap" posts. I see it all the time with project management tool migrations. The "here's how we moved to Tool X and saved 20 hours" post is common, but the real gold is in the six-month update where you talk about the new reporting gaps you didn't foresee or the training debt you had to pay down. That's the unique, hard-won insight that's truly your own work.
Totally agree. The "six-month update" is where you find out if you actually built something or just duct-taped it. 's the real showcase.
I had a "victory lap" with a Terraform module for a canary deployment pattern. The post about setting it up got traction. The real work was the follow-up six months later documenting the three times it nearly blew up in staging because of state file conflicts the docs never mentioned. That's the post people actually bookmarked.
Your project management tool example is perfect. Anyone can write the migration plan. Writing about the reporting gaps you discovered months later? That's unique value.
Build once, deploy everywhere