wip: hardened issue template

[pazos]

Shameless copy from brew's bug template

Adapted to document crash.log creation and test case reports for documents. The main idea is to make our lives easier.

1. avoid incomplete bug reports
2. avoid out-of-date bug reports
3. avoid including our own instructions on the body of the new ticket
4. prevent us from explaining how-to get debug logs on each ticket

---

This change is 

[poire-z]

Why not.
How will this look? Just like this?:

I'm not sure all users will understand they have to remove <!-- replace me --> and we won't see ( :) ) <!-- my issue is this and that --> :)

As for always enabling debug logs, that might be a bit excessive: we'll have 2Mb crash.logs to look at - and sometimes, if it ends with a Lua stack trace, that's quite enough.

(What I'd really like is for issue titles to have a length limit - to make it harder on arooni :)

[Frenzie]

Other inspiration: https://obsproject.com/blog/how-to-contribute-to-open-source

[Frenzie]

For context
Homebrew/brew@6676e40

https://github.com/Homebrew/brew/pull/3085

[Frenzie]

@poire-z

I'm not sure all users will understand they have to remove and we won't see ( :) ) :)

Also note how I put it in the feature request template, which I think has been very successful. Feature requests have been much clearer and more targeted.

Does your feature request involve difficulty completing a task? Please describe.
A clear and concise description of what the problem is. Ex. I think it takes too many steps to [...]

[pazos]

How will this look? Just like this?:

Yeah.

I'm not sure all users will understand they have to remove and we won't see ( :) ) :)

Valid point, @Frenzie suggestion works for me.

As for always enabling debug logs, that might be a bit excessive: we'll have 2Mb crash.logs to look at - and sometimes, if it ends with a Lua stack trace, that's quite enough.

Maybe: "Unless you're reporting a crash you're required to enable debug logs first."

[pazos]

Follow up: pushed this to my master branch too, so the changes here can be previewed in https://github.com/pazos/koreader/issues/new/choose

[Frenzie]

I have to wonder if we can't keep it a little bit more concise? But looks fine in principle.

[poire-z]

Not super fond of the tone :) and the heavy wrapping (10% user text for 90% static text probably). I'm usually quite fine with a single sentence and most often, they make sense even if the version/device is not provided.
(I'm quite sure we'll get unreadable stuff with people getting lost in the markdown and HTML comments - and messed up issues we'll probably have to edit to make them readable :/)
But we can try it.

[pazos]

I have to wonder if we can't keep it a little bit more concise? But looks fine in principle.

Segmentation of text based on the nature of the bug/feature?

For example, a few quick templates:

1. Bug - core (unexpected behaviour on the logic)
2. Bug - UX (unexpected behaviour of the interface)
3. Bug - document (unexpected behaviour rendering or dealing with a document)
4. Bug - device (unexpected behaviour dealing with a supported device)
5. Bug - plugin (unexpected behaviour on a specific plugin)
6. Bug - other (other kind of reproducible issue)
7. Feature - core (an enhancement in the logic of the program)
8. Feature - UX (an enhancement in the interface of the program)
9. Feature - plugin (maybe redirected to discussions and saying: ask first if something like that is nice to have)
10. Feature - document rendering (improvements on document rendering)
11. Feature - document type (maybe redirected to discussions and ...)
12. Feature - other (redirect?)

[pazos]

Not super fond of the tone :)

Is a bit harsh for me too :/. Specially the part of If you repeatedly fail to use the issue template, we will block you from ever submitting issues to KOReader again

[poire-z]

Please note we will close your issue without comment if you delete, do not read or do not fill out the issue checklist below and provide ALL the requested information. If you repeatedly fail to use the issue template, we will block you from ever submitting issues to KOReader again.

Please read and fill out the issue checklist below, and provide all requested information. If you don't, a kitten will be killed and you won't be our friend. If you end up repeatedly killing kittens, we will block you from submitting issues and killing more kittens.

[Frenzie]

@poire-z

Not super fond of the tone :) and the heavy wrapping (10% user text for 90% static text probably). I'm usually quite fine with a single sentence and most often, they make sense even if the version/device is not provided.

I'm on the same page. I don't like the brew bug templates. They're for developers, not users.

@pazos

For example, a few quick templates:

That's far too many, but we do need a document bug template, mainly to direct people to programs like epubcheck.

[poire-z]

Still wip ? Or are we fine with our soft template ?

[pazos]

Leave it wip. I will try to make it soft while keeping some stuff than can make our janitor tasks easier :)

[poire-z]

The following first post has some links to some issue template which happens to look like what you wanted, but also quite more html-form-like than what you got above :)
https://github.com/arkenfox/user.js/pull/1386

[Frenzie]

but also quite more html-form-like than what you got above :)

Yeah, GitHub Issue Forms are new since roughly half a year ago. They still say "Note: Issue forms are currently in beta for public repositories on GitHub.com only."

I don't like a bunch of meaningless checkboxes and too many required fields but it could be useful to absolutely require the version. It surprises me a bit but there's been a number of issues where it turned out the OP was using a version from over a year ago.

[zwim]

Are there any new thoughts/insights here?

[pazos]

Are there any new thoughts/insights here?

Not really. I've commented elsewhere: #8902 (comment)

We could stick something like this on a wiki page perhaps? (Plus some stuff about those paths.)
https://freshrss.github.io/FreshRSS/en/contributing.html

Created https://github.com/koreader/koreader/wiki/Report-a-bug as a proof of concept