If we leave this line here, then it should be made clear which parts can be skipped if they do not apply. See below.

Rollup has no runtime dependencies so we could remove the npm version, unless they are having TypeScript typing issuese.

That's reasonable. Will update.

I'd say the Rollup version is always relevant. The second line could be:

• Operating System + Node Version (or other Runtime Environment/Browser):

And I agree, the NPM version will probably not be relevant as all NPM specific functionality is usually handled by rollup-plugin-node-resolve.

I'm down with removing the NPM version as a requirement, especially given how Rollup is shipped.

I hate repository links, as it always seems like a great way to put a backdoor onto a maintainers machine to me (npm install is executing).

2. Work to isolate the issue and write out the exact steps in the issue here.
3. Include a minimal GitHub repo link. These may take more time for us to look into than the above.

I'm good with this change. For consensus @lukastaegert please weigh in on it (Lukas had previously asked for the REPL and repo link in order from the template on master).

I think I am ok with @guybedford's change as it would still encourage the creation of a repo albeit with lower priority. From the debugging perspective, they can be a huge shortcut but I see the security concerns.

Maybe in the future we could work to extend the REPL to be able to reproduce more situations by adding a way to designate multiple entry points (maybe a simple checkbox above each module?) and some way (cogwheel button?) to provide a select set of config options that would make sense here.

👍

Maybe we could add something like: If you think Rollup's documentation is unclear, insufficient or wrong, consider creating an issue for the documentation instead.

Done, nearly verbatim.

👍

These guidelines seem important to me to keep. Or perhaps reword into the template?

The first point (about an accompanying issue) I've found that with new features, there's often more work done on implementation before discussion starts, if the contribution is coming from outside contributors, which is then discussed directly on the PR. I've also found it can be a hinderance to contribution if there's too much process but I'm completely OK with adding that back in. If you feel there's more value to the process than risk of dissuading contributions, I'm good with that.

I can get behind what you're saying certainly in not crowding the process here.

Perhaps a note saying they should research previous discussion on the feature by searching the issues first?

Great idea. Definitely a step that should always happen.

Committed proposed additions based on that feedback.

Huge thumbs up from me for making this the top priority! Hope at some point to write up a short guide to writing tests that we could link to from here.