[GitHub Issues]: Adding Templates for issues for better reviewability

[EverydayBitcoiner]

Current Situation
As I have been going through SeedSigner issues I have thought that there could be a better way to organize new issues and found out that GitHub supports templates for creating issues. Currently all new issues use the same format and that can make it a little more difficult to filter through issues and figure out what an issue is about.

---

Proposed Action
I have made some sample templates that can be seen in my seedsigner repository issues (Note: the templates will only be active when they are part of the default branch for the repo). These are just some basic templates that I copied and edited from examples in the GitHub documentation and adjusted them to fit some of SeedSigner repo needs. These templates can automatically assign labels and assign ownership of issues if desired. In the example template for a feature request I also added a spot where the requester can offer to put up a bounty for the feature (just an idea).

Additionally I am wondering if it would be beneficial to enable discussions in the seed signer repo. You can see what discussions look like on the BlueWallet repo. I think it could be a good place for people to ask questions, get answers, share builds, discuss ideas that may not be the point of creating a new issues, etc. I have not previously used discussions so I cannot speak from experience, but it may be useful for the community. This could also be a place to redirect people that have questions or need help and avoid creating new issues that are not actual issues, but rather questions.

---

Example List of Issue Templates

BlueWallet Repo Discussions

[jdlcdl]

I won't pretend to have an experienced/informed opinion on this because I'm new to github, but I can imagine that categorized issues would be helpful.

I'm here to help and NOT to criticize what I believe is a very important project that has progressed just fine without me... but I will share that it's my belief that a more timely reactivity to recent comments, and for issues that seem closed to be closed so they drop off the list, and more links between issues that are related... JUST AS YOU HAVE BEEN DOING, might encourage existing and new devs to spend more of their valuable talent and time dedicated to this repo. Saving them time by allowing them a path to find what they're looking for faster is consistent with that goal.

I'd hate to see that talent drops-in and then drops-out towards another project simply because they didn't have enough feedback, or timely enough feedback, to realize that they were making a valuable difference. It's just my 2c @EverydayBitcoiner, but if you'd ever spent as much of your free time trying to make my project better, I'd have snatched you up in a heartbeat and pulled every string I had with hr to lock you in. Good job once again.

[EverydayBitcoiner]

@jdlcdl, thanks for the thoughts.

As someone who has spent quite a bit of time over the last couple of weeks looking over the issues in this repo with fresh eyes I can say that more structure and format would have helped me filter through and review them more efficiently.

Do you have any suggestions/thoughts on the actual forms? Both the categories for the forms and the forms themselves? I think they are good enough to at least start with, but would love if you could just give them a quick review (link is in the original post)

Also, would love to hear your thoughts on the GitHub Discussions idea. I know you're new to github, but maybe go poke around on the BlueWallets discussion board, jellyfin's, or any other one's you see. Just want to know if something like that would be beneficial. IMO I think it would be.

[jdlcdl]

Thank you for asking me to put more time into this because I do have input even if Im new to github, and you undoubtedly deserve the feedback. Also, thanks for expecting better of me... I deserve that too.

Now that I've taken a chance to look at your templates, I find that they convey respect and gratitude to the person who is about to fill them out... starting out with a "thank you!" is classy. Also, I'm long-winded, and having a template that asks specific questions keeps me in check, saving every other reader time (while improving on me).

I notice that this allows the user to default the first "label", which not all of our issues have, but which would be very helpful for readers when done in good faith, so that an admin doesn't have to maintain it. I'm assuming that doing this does not keep an admin from re-labeling an issue that is not categorized appropriately or outright mislabeled in bad faith.

As for the categories, I can imagine myself and others monitoring the BUG label w/high priority... keeping that list small with each issue addressed asap. The others match up pretty well with existing labels and I like the addition of "hardware", for current hardware problems as well as future hardware possibilities.

I ABSOLUTELY LOVE the idea of adding a bounty option for feature-request/enhancement, and it might not hurt to offer this for r&d, hardware, gui. You did this without making it sound like "begging" which I happen to be very sensitive about, Nicely done! Many users of seedsigner will be coming from a profitable enterprise and it would be silly NOT to present the possibility for them to express how valuable this issue is to them; it will help others to prioritize servicing an issue that might not otherwise seem valuable from the dev's perspective.

Since you've been so respectful in your wording of the form, It might NOT be necessary to mandate that the user clicks the "I've searched existing issues", because they'll see that they merit shame if they have not done so, others will too. Also, any required fields might reduce the conversion rate of filling out and submitting the form, especially for a bug report, might require too much time, resulting in "Why so difficult? I don't have time right now, it's just not worth it!". This opinion might bite me, but I'd rather start off with an easy "fill it out free form" so that we get the info and can chase down important issues -- assuming best-faith of our users, until proven otherwise. For each form however, I do believe the first textarea field might be *required since a blank form is useless... but also easy to clean-up assuming admins can do so.

I will get back to you about the github discussions once I've taken a look at bluewallet discussions. I've heard the opinion recently that github is a bit "too impersonal" and I'm aware that there is a new telegram group that was setup to welcome new seedsigner-devs. Perhaps github discussions would be redundant in parallel... then again, it's also another anon account to maintain for anons who don't care for telegram.

[jdlcdl]

As for github discussions, this feels like the free-form issues that we currently have. I like that it might be an informal version of issues, which would be missing given that your proposal of issue-templates were adopted... or is it possible to ALSO have a free-form issue template??? What would be the difference between discussions and a free-form issues template, if that's even possible? It does add one more tab on the github page, and less is usually more.

If it's NOT possible to have both issue-templates and a free-form issue-template, then I think discussions are almost necessary to replace what we already have. The way that you've included the link to discussions at the bottom of your "open new issue" page feels perfectly natural to me... if my issue doesn't fit a template, my next choice is a free form discussion.

[EverydayBitcoiner]

I notice that this allows the user to default the first "label", which not all of our issues have, but which would be very helpful for readers when done in good faith, so that an admin doesn't have to maintain it. I'm assuming that doing this does not keep an admin from re-labeling an issue that is not categorized appropriately or outright mislabeled in bad faith.

The default label is set in the template and will be automatically applied based on the template that was used. Could you edit the label when you submitted that issue on my repo? The issue submitter should not be able to add extra labels or change the default one.

As for the categories, I can imagine myself and others monitoring the BUG label w/high priority... keeping that list small with each issue addressed asap. The others match up pretty well with existing labels and I like the addition of "hardware", for current hardware problems as well as future hardware possibilities.

I tried to make these categories by going back and looking through previous issues and tried to figure out template that made sense for what we've seen. These can also be edited at a later time if needed.

I ABSOLUTELY LOVE the idea of adding a bounty option for feature-request/enhancement, and it might not hurt to offer this for r&d, hardware, gui.

I like the idea of expanding it to those other issues you mentioned.

Since you've been so respectful in your wording of the form, It might NOT be necessary to mandate that the user clicks the "I've searched existing issues", because they'll see that they merit shame if they have not done so, others will too.

Not sure if I'm with you on this one. I'm not expecting new submitters to dive into each issue, but rather have at least done a few simple searches to see if the issue has already been brought up (could make that clearer). Not sure where the shame component comes in because a submitter just won't be able to submit an issue unless they check the box. Just more of a strong nudge to avoid creating duplicate issues which IMO are more embarrassing to submit.

I've heard the opinion recently that github is a bit "too impersonal" and I'm aware that there is a new telegram group that was setup to welcome new seedsigner-devs. Perhaps github discussions would be redundant in parallel... then again, it's also another anon account to maintain for anons who don't care for telegram.

One of the main things that I think GitHub discussions could be useful for is Q&A for general SeedSigner users because I think the format is much more conducive to searching and referencing than telegram. I think the dev telegram is great for more informal conversation that will eventually be refined and put into an issue or something else on GitHub. I think GitHub discussions could also be useful for a more informal discussion/polling about features or other things and for refining ideas before creating a formal issue.

What would be the difference between discussions and a free-form issues template, if that's even possible?

Free form issue template would be easy to make or the default one is still available (though not super visibly I just missed the hyperlink text for it in my screenshot above, it's just below the very bottom).

The topics in discussions can also be changed to fit SeedSigner community needs (see below).

[jdlcdl]

Could you edit the label when you submitted that issue on my repo? The issue submitter should not be able to add extra labels or change the default one.

I confirm that I'm not offered the chance to alter the "BUG" tag when editing the issue I submitted on your repo last year.

Not sure where the shame component comes in because a submitter just won't be able to submit an issue unless they check the box.

I meant that if it is not required to check the box... they'd see that they didn't even search to see if they're submitting a duplicate as soon as they re-read what they've submitted, after having been so politely asked to do so, and everyone else would see it too. I'd have shame to be so careless, and then I'd go search and delete my duplicate. ;) No worries that it's required, not doing so would eventually bite, and it's a nice test to see if they're conscientious about checking "I've searched".

[EverydayBitcoiner]

Wow! That image I pasted showed up way bigger than I intended 🤣.

I confirm that I'm not offered the chance to alter the "BUG" tag when editing the issue I submitted on your repo last year.

Can you edit it if you create a new issue? I am guessing no. That is how it should be.

I meant that if it is not required to check the box... they'd see that they didn't even search to see if they're submitting a duplicate as soon as they re-read what they've submitted, after having been so politely asked to do so, and everyone else would see it too. I'd have shame to be so careless, and then I'd go search and delete my duplicate. ;) No worries that it's required, not doing so would eventually bite, and it's a nice test to see if they're conscientious about checking "I've searched".

Ah, I see what you mean. I don't think it's necessary to do it like that. I intended it to be a reminder that can't be ignored. As a user I would appreciate this as a reminder so I don't make a fool of myself when I may not be familiar with GitHub, or just not familiar with how things work.

[jdlcdl]

Can you edit it if you create a new issue? I am guessing no. That is how it should be.

As I clicked to create a new "feature request" issue in your repo, I was able to muck with the title's [prefix] but this didn't convince your template to label it as a bug, it was labeled as an enhancement, as you suspect above.

[EverydayBitcoiner]

As I clicked to create a new "feature request" issue in your repo, I was able to muck with the title's [prefix] but this didn't convince your template to label it as a bug, it was labeled as an enhancement, as you suspect above.

Yeah, I wish their was a way to lock the first part of the title, but I haven't seen one yet.

[EverydayBitcoiner]

Would something like this help?

[jdlcdl]

It might, or maybe I'd still miss it. I won't pretend to have never sent an email without a subject.

When the form loads for me, the cursor is right in that field with a border highlighting it. It's pretty obvious as it is, but it's true that when the field is empty, we see the faded hint that we should add a title.

Looking at our existing issues, I like that others have prefixed their titles w/ "[category]" so I think I prefer that you've defaulted that as well in the title, as opposed to defaulting it empty.

[SeedSigner]

This is good discussion and I am especially sensitive to this comment "I'd hate to see that talent drops-in and then drops-out towards another project simply because they didn't have enough feedback, or timely enough feedback, to realize that they were making a valuable difference." Much to his credit, @newtonick volunteered to do periodic maintenance with issues, applying tags and closing items as necessary. Some of the challenges evolve from the nature of our work on the project being part time and something that we catch up on as we're able, but more hands potentially makes for lighter work and we definitely appreciate the interest in developing and growing our project. Am curious to hear @newtonick's thoughts on the above template system.

[jdlcdl]

Just to add, something I've learned with github (I've mentioned this in telegram) is to immediately sort issues/prs by "recently updated", with the intent of becoming aware of feedback and also to return that favor as quickly as possible... in the spirit of "the tighter the feedback loop, the closer we remain to on-target". If github allows setting this sort param as a default, this would be my 2c preference, but if not it's already a default habit for me.