Repository: electron
Issue: [Docs] Page that explains once and for all why a good issue reproduction is necessary
Labels: enhancement :sparkles:

### Preflight Checklist

- [x] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [x] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/main/CODE_OF_CONDUCT.md) that this project adheres to.
- [x] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a feature request that matches the one I want to file, without success.

### Problem Description

I've seen many Github issues recently where the author either

* Put a complicated Github repository as the reproduction,
* Posted small code blocks that weren't executable on their own as the reproduction, or
* Didn't post a reproduction (e.g. because they thought it would be trivial for maintainers to build one in 15 minutes)

This is annoying. It wastes maintainers' time.

Every time, a maintainer will explain over and over again why a repro through Fiddle is necessary for the team to look into the issue.

Often, people will argue back that their reproduction is "simple enough" or something similar.

### Proposed Solution

Write a doc explaining once and for all why a repro through Fiddle is necessary.

Then everyone can link to it when someone doesn't post a reproduction or tries to argue.

@dsanders11 recently put it very nicely: "We're not trying to be difficult, we just have a lot of issues to triage and prioritize those with a minimal repro case."

Points to mention:

* Why provide a good reproduction?
  * The Electron team is busy. If you don't supply a simple repro, they won't have time to investigate your issue.
  * If you want someone to spend time on *your* issue, make it as easy as possible for them.
  * The easier you make it for maintainers to reproduce your issue, the higher the chances that your issue will be solved.
  * If you want your issue to be fixed, put in the small amount of time that it takes to make the issue easily reproducible for maintainers.
  * In simplifying the issue to a small reproducible example, you might sometimes discover bugs in non-Electron parts of your code that lead to the faulty behavior (instead of it being an Electron issue). Then you'll have a solution for your problem sooner.
  * Cloning arbitrary repos might expose maintainers to security exploits / vulnerable code. They don't have time to check multi-file repositories for security vulnerabilities.
  * A good reproduction ensures everyone is talking about the same issue.
  * Issues that don't provide a repro through Fiddle will be closed.
  * More inspiration in the comments to issue 45251 (not linked because I don't want the author to feel bad)
* What is a good reproduction?
  * A good reproduction only contains the minimum amount of code necessary to reproduce the issue. Remove any code that is not absolutely necessary to reproduce the issue. (This makes debugging easier as there is less code for which the maintainers have to check whether it causes the issue.)

Below that, I'd add an FAQ-style list of responses to common objections (e.g. "the reproduction is simple enough" or "you're the maintainer and responsible for fixing this—build one yourself").

Afterwards, the link could be placed in the following places:

* In the issue template as a comment
* In the automated message sent when the `blocked/needs-repro` tag is added

### Alternatives Considered

#### 1) Maintainers summarize the same points over and over again.

1) This is time-consuming.
2) Every comment on this topic that's written individually will be worse than a comprehensive doc that provides an exhaustive answer once and for all.

#### 2) The automated message from the bot that is added when the `blocked/needs-repro` tag is added

While this is helpful, it happens very often that people argue with the message, saying that their reproduction is simple enough or similar. Then this wastes maintainers' time again.

I suggest to have an FAQ at the bottom of the document with responses to these common objections.

### Additional Information

**Inspiration:** https://levels.io/contact/ ([archived version](https://web.archive.org/web/20241116010936/https://levels.io/contact/))

**Issues that inspired this suggestion:** 44264, 44690 (not linked because I don't want the authors to feel bad)