Product Feedback as Community Work — How I Log Bugs and Feature Gaps That Count for MVP

The Sitecore MVP criteria page is blunt about bug reports. A submission counts when it is a confirmed bug, a feature request, or missing documentation, and the reviewer has to be able to validate it. A paragraph that says the AI felt wrong does not clear that bar. A thread of screenshots with no version, no steps, and a secret still visible in the network panel does not clear it either, and it creates a security problem on the way. I log product feedback because the products are moving fast enough that a real gap, written once, saves the next implementation team the month I just spent. The MVP program's public rules happen to reward the same habit. This is the log I keep so a note can survive both a support engineer and a community reviewer.

What the program actually lists

The public "how to become an MVP" page groups contributions into content, engagement, public speaking, and feedback. Feedback and references include support tickets, product feedback through MVP channels or directly to product managers, beta testing of products and trainings, customer references, and participation in the advisory boards Sitecore runs. The page asks for a balanced application, a minimum of five contributions and a maximum of thirty that you consider your best, a link a reviewer can open, and the Sitecore product the contribution relates to. It tells you not to paste every social post as its own line. Quality is the word they repeat.

The About page says the same thing in the Technology and Ambassador descriptions: regular product feedback is part of the work, alongside writing, speaking, and helping people in public channels. None of that is a request for a private complaint. A locked spreadsheet of frustrations is not a contribution anyone can validate. I assume a reviewer will open the link and decide whether the item is real. I write the item so that a stranger can.

I do not treat this post as an application, and I do not treat a count of tickets as a strategy. The February 2026 MVP announcement described a class of 213 people and a review run by community reviewers. The bar they published is influence and real contribution. A fabricated ticket number would fail the only test that matters, which is that the link resolves to the thing I claim. If I cannot share a link, I do not list the item. Some customer work cannot be linked. Those tickets still get written well, for the customer's sake, and they stay off a public application unless the customer and Sitecore have made them something a reviewer can see.

How I write a bug so it can be confirmed

A report that comes back confirmed has the same parts every time. The product and the version, taken from the UI or the package, not from memory. The environment, named as non-production unless production is the only place it happens. The steps, from a clean session. What I expected, with a link to the documentation page that created the expectation. What happened, with the response body trimmed of tokens, cookies, and email addresses. What I already ruled out.

The last section is where most of my early reports were weak. "Cache" is not a ruled-out cause. "I published, queried Experience Edge for this item id, saw the new field, and the editing host still rendered the previous field" is a ruled-out cause. Support can confirm a defect. They cannot confirm a mood. When the ticket comes back as a configuration mistake, I leave it in my notes as a configuration mistake. The MVP guidance is explicit that an unconfirmed bug is not the contribution to list. I would rather keep a short list of confirmed items than argue a rejected ticket into the form.

Missing documentation is its own category and I used to file it as a bug against the product. The better report says "this page describes defineMiddleware, this package's scaffold emits defineProxy, here are both versions." That is a documentation defect a writer can close, and it is the sort of gap that shows up constantly across Content SDK releases. A feature request says what I could not do, who hits it, and what workaround I used. "Make agents smarter" is not a request. "The custom-field JSON written by the Agent API bypasses the Marketplace modal, so invalid icon names publish as empty components; a server-side validation hook on that field type would stop the write" is a request.

I attach the smallest sample that fails. A three-line component and a template id, not our client's design system. I remove organization names from exports of agent flows before the file leaves the tenant. The flow definition is configuration. It is also full of site names and prompts that were never meant to be public.

Where each kind of note goes

I pick the channel from who can act, not from where I happen to be typing.

Sitecore support receives defects in a product we have a contract to run: a connector that fails with a traceable error, a webhook that never fires, an editing host that returns a response the docs say is valid. The ticket id is the record. If support confirms the bug, the id and the confirmation are what I keep.

The public SDK repositories receive defects in the open-source layer. Content SDK, the starter, the Marketplace SDK. An issue there has a version, a reproduction in a public repository or a minimal repo, and no customer content. I do not open a GitHub issue to ask Sitecore to change a commercial entitlement. I do open one when createSitecoreRevalidateRouteHandler and the tag written by the cache helper disagree in a specific version and I can show both strings.

Documentation feedback goes to the page that is wrong. A sentence that still tells a SitecoreAI team to install JSS as the only JavaScript SDK is a doc bug. I quote the sentence, I quote the lifecycle note that superseded it, and I name the date I read both. That is more useful than a general "docs are out of date," which has been true in some corner of every platform I have shipped on.

Product feedback that is a gap rather than a broken build goes through the channel the audience can actually read. For a public technique, I write the pattern up, the way the rest of this month's posts are written, and I describe the missing product behavior as a missing behavior. For a customer-specific issue, I talk to the account team or the product contact we already have, and I bring the same written note I would have put on a ticket. I do not save the clear version for a nomination form and send support the vague one. The form gets a link to work that already existed.

Beta programs, when I am in one, get notes during the beta rather than a surprise list afterwards. A beta bug filed after general availability is just a bug. The point of the early access is that the report can still change the release.

A template I paste into the top of the note

Product:
Version / package:
Environment: (non-prod tenant, region, head runtime)
Expectation: (doc URL and the sentence I relied on)
Steps:
1.
Actual:
Ruled out:
- Published to Edge? (item id, timestamp)
- Reproduced on the clean starter? (yes/no, repo link)
Customer data removed: yes
Ask: confirm bug / correct the doc / consider this feature

If I cannot fill "Ruled out," I am not ready to send it. If I cannot fill "Customer data removed," I am not allowed to send it. The ask is one of the three outcomes the MVP page already uses, and forcing myself to pick one stops me from filing a feature request that is really a misunderstanding of the current tool.

I keep a personal index with the date, the channel, the link or ticket id, the product, and the outcome: confirmed, fixed in a named release, documented, rejected, or still open. The index is for me. The link is for anyone else. When a workaround lands in a blog post, the post links the issue, and the issue links the post once the workaround is real. That loop is the community part. A private index alone helps the next me. A public write-up helps the next person who hits the same release note.

What I refuse to log

I do not log a security incident in a community forum. A suspected exposure of a client secret, an automation token in a front-end bundle, or a webhook that accepts unauthenticated purges is a support and incident process. I rotate the secret first. The write-up, if I ever publish one, describes the class of mistake after the customer is safe, without the secret and without a recipe for finding someone else's.

I do not log other people's tenants, and I do not log a guess about a roadmap as if it were a defect. "Sitecore should acquire X" is not feedback about a product I implemented. "This API returns 200 and an empty variantIds array when the page variant is published only to the web database and not to Edge" is feedback, provided I have checked both sides.

I do not split one investigation into ten tickets to make a longer list. The page that says quality rather than quantity is doing reviewers a favor. It also matches how I want support to treat me. One well-scoped ticket gets a confirmation. Ten overlapping ones get a merge and a sigh.

The habit, independent of any nomination

When I hit a wall, I write the expectation and the doc URL before I write the complaint.
I reproduce it on a clean starter or I say why I cannot. I strip customer data either way.
I send it to the channel that can close it: support, the SDK repository, the docs, or the product contact.
I record the outcome next to the link. Confirmed, or not. Only the confirmed bug, the feature request, or the missing-doc item is a contribution I would hand a reviewer.
If the workaround is general, I publish the workaround and point it at the same link.

Product feedback is community work when another team can use the confirmation. It is paperwork when it is a feeling with a screenshot. The MVP program publishes a precise version of that distinction, and it matches the version I want on a project even in a year when I submit nothing at all. The log is the same either way. A stranger should be able to follow it, and Sitecore should be able to say whether it is real.