Guide: How to structure your evaluation request post for good feedback

Hey folks! 👋

Over in the CI/CD and Monitoring subforums, I've noticed a common pattern: when someone asks for feedback on their pipeline config or dashboard setup, the quality of the replies they get is *directly proportional* to the clarity and detail in their initial post. A vague request gets vague, generic advice. A structured, detailed one? That's where the magic happens—you'll get actionable, nuanced feedback from folks who've been in the trenches.

After reading dozens of these threads, I wanted to share a kind of "template" or guide for how to structure an evaluation request post. Think of it like providing good logs and metrics for an incident—context is everything!

### Why Structure Matters
When you're asking busy engineers to pore over your YAML or your query, you're asking for a slice of their time. Making it easy for them to understand your goal, your constraints, and your current setup is respectful and *practical*. It leads to better help, faster.

### A Suggested Structure for Your Post
Here’s a format I’ve found works really well. You don't need to follow it slavishly, but hitting these points will cover 90% of the needed context.

**1. The Goal**
Start with a single, clear sentence. What are you trying to achieve?
> *"I want my automated canary deployment to roll back faster when error rates spike."*

**2. The Context**
Briefly describe the application, team size, or critical constraints.
> *"This is for a customer-facing payment service running on Kubernetes. We have a 4-person SRE team. Our SLA requires 99.95% uptime."*

**3. The Current Setup**
This is the meat. Provide your relevant code, config, or screenshot. For a pipeline, show the relevant stage. For a dashboard, share the query and a screenshot.
```yaml
# Example: A problematic pipeline stage
- name: deploy-canary
run: |
./scripts/deploy --strategy canary --percentage 25
- name: monitor-criteria
run: |
# This sleep is what feels wrong!
sleep 300
./scripts/evaluate-metrics
```

**4. The Specific Pain Point or Question**
What exactly are you unsure about? What feels wrong? Be precise.
> *"The 5-minute sleep feels like an anti-pattern. I want to replace it with a dynamic wait based on Prometheus alerts, but I'm not sure how to structure the feedback loop cleanly within the job."*

**5. What You've Already Considered**
List the alternatives you've ruled out or tried. This prevents redundant suggestions.
> *"I've looked at Argo Rollouts' analysis template, but we're not ready to adopt a whole new tool. I also considered a dedicated webhook listener, but it adds operational overhead."*

**6. The Ask**
Finally, state what kind of feedback you're seeking.
> *"I'm primarily looking for: 1) Patterns for integrating Prometheus alert checks into a GitLab job, 2) Any potential race conditions I might have missed, 3) Alternatives to the sleep command that are more resilient."*

### The Payoff
Using a structure like this does a few things. It forces you to clarify your own thinking first. It shows the community you value their expertise. And it practically guarantees you'll leave with concrete, implementable next steps.

What do you all think? Would you add or remove any sections? Have you found other formats that work well for getting deep, technical feedback?

—jr