Add bug issue templates (#758)

[thebrandonlucas]

Copies and makes modifications to Bitcoin Core's
bug issue template where appropriate.

If we'd like I'll make a PR containing the following templates next. This does not take long and with the exception of SECURITY.md can mostly be adapted from Bitcoin Core:

• Feature Request
• SECURITY.md
• Good First Issue
• General Question / Support

[thebrandonlucas]

Bitcoin Core's bug template has mentions of where to go for other issues (namely security & general questions/support) here. I think it would be good for us to have those as well, but I wanted to submit the most helpful template first. I think it would also be helpful to add "Good First Issue" template and "Feature Request" templates, all of which can be easily adapted from Bitcoin Core.

Regarding SECURITY.md, I'd need clarification on what info should go there if we're ready to do that. Payjoin seems like an important project to have that in but perhaps we want to have formal security reviews first.

When I do the SECURITY.md file, I'll put that and CONTRIBUTING.md in the root of the repo as initially requested, and to match Bitcoin Core.

[coveralls]

Pull Request Test Coverage Report for Build 15933192835

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 36 unchanged lines in 17 files lost coverage.
• Overall coverage decreased (-0.6%) to 85.506%

---

Files with Coverage Reduction	New Missed Lines	%
payjoin-directory/src/lib.rs	1	75.0%
payjoin/src/ohttp.rs	1	70.97%
payjoin/src/receive/mod.rs	1	98.13%
payjoin/src/receive/multiparty/mod.rs	1	89.86%
payjoin/src/receive/v1/mod.rs	1	95.74%
payjoin/src/receive/v2/session.rs	1	94.02%
payjoin/src/send/v1.rs	1	94.7%
payjoin/src/send/v2/mod.rs	1	88.13%
payjoin-test-utils/src/lib.rs	1	94.41%
payjoin-cli/src/app/config.rs	2	81.58%

Totals
Change from base Build 15905219803:	-0.6%
Covered Lines:	7262
Relevant Lines:	8493

---

💛 - Coveralls

[thebrandonlucas]

I could use clarifications on the best wording to put here.

[nothingmuch]

Perhaps we should split this up into two bug templates, one for the payjoin crate, and one for everything else?

For the payjoin crate I think we want to know whether they're using FFI, and if so what host language, etc, what features flags they enabled on the crate, and the rust version.

For everything else, i think what primarily matters whether or not they built it themselves (and if so with what features) or if they're using a binary release or the docker image, and perhaps information about the machine or environment, but I suspect that most issues would be for the payjoin crate where that information is far less likely to be relevant.

[nothingmuch]

Oops I meant to post a comment review, not request changes since I didn't make concrete suggestions.

[thebrandonlucas]

Perhaps we should split this up into two bug templates, one for the payjoin crate, and one for everything else?

For the payjoin crate I think we want to know whether they're using FFI, and if so what host language, etc, what features flags they enabled on the crate, and the rust version.

For everything else, i think what primarily matters whether or not they built it themselves (and if so with what features) or if they're using a binary release or the docker image, and perhaps information about the machine or environment, but I suspect that most issues would be for the payjoin crate where that information is far less likely to be relevant.

Great points, I can modify it to have one for the payjoin crate and one for the others

[thebrandonlucas]

@nothingmuch I split this into two as you suggested. One for the payjoin crate, one for the rest. Let me know what you think

[nothingmuch]

ACK

I opened a new issue for the log question, I don't think it should block merging of this.

[nothingmuch]

My main concern with this is that users might not understand the privacy consequences of certain log messages, maybe it's better to suggest info instead of debug until we've scrubbed those, and to warn specifically against trace which is not safe?

Also the RUST_LOG suggestion seems to apply to the tools crates too?

[thebrandonlucas]

My main concern with this is that users might not understand the privacy consequences of certain log messages, maybe it's better to suggest info instead of debug until we've scrubbed those, and to warn specifically against trace which is not safe?

I like that suggestion and can modify that in a subsequent PR

Also the RUST_LOG suggestion seems to apply to the tools crates too?

I like this idea but not all crates are setup with logs. For example payjoin-directory does not output logs when prefixed this way, its' behavior is unmodified

[nothingmuch]

I like this idea but not all crates are setup with logs. For example payjoin-directory does not output logs when prefixed this way, its' behavior is unmodified

Hmm, are you sure? trace level outputs are definitely there, there's not many debug level calls though i think only a serve_payjoin_directory

[nothingmuch]

I forgot to say i created #821

[thebrandonlucas]

Hmm, are you sure? trace level outputs are definitely there, there's not many debug level calls though i think only a serve_payjoin_directory

Ah, it appears I was tricked into this by not seeing any output when I used DEBUG (from this issue). My mistake.

[nothingmuch]

• Feature Request
• SECURITY.md
• Good First Issue
• General Question / Support

I'm in favor

(sorry for leaving this question in the merge commit message)