Add required fields to the issue template

[nugraha-abd]

This PR aims to improve the quality of the posted issues by making the must-fill fields to be required. In order to achieve that i create new template files which use YAML format called bug-report.yml and feature-request.yml and deleted the existing bug-report.md and feature-request.md markdown template file.
Often times there are issues that don't respect the template, for instance failing to mention the installed version. Hopefully this new template could tackle that type of problem.

Here are the fields added to the template, the required fields are marked by asterisk

bug-report.yml

• Bug Description *
• Expected Behavior *
• Frequency *
• Steps to Reproduce *
• App Version *
• Android version and ROM used *
• Device (not strictly required due to privacy reason)
• Additional Context

feature-request.yml

• Feature Description *
• Use Case *
• Alternative Solution
• App Version *

Here is a video preview on how the new template would look:
Screencast_20260717_174905.webm

There are two questions that I’d like some input on:

1. Should I keep the tl;dr or remove it since I already listed all of them in the checklist?
2. Do any of those fields require modification? For example, making it optional instead of required.

[Helium314]

I still need to think about that.
Users providing the necessary information would help, but also I always strongly disliked such templates because they feel bulky and at times require you to input something that isn't necessary or applicable.

Anyway, currently the even worse problem is that I simply have way too much to do with PRs alone... I haven't even looked at an issue recently other than clicking links in PRs.

[maruuk]

I think it would be good to add a point to the checklist about the requirement to use English. Some people open issues in other languages ​​🙄

[Helium314]

Should I keep the tl;dr or remove it since I already listed all of them in the checklist?

I added it because some people seem to be unwilling to read a few lines unless I write them individually for them, but I got the impression that group also doesn't care about the shorter text. So maybe that can go away.

[nugraha-abd]

they feel bulky and at times require you to input something that isn't necessary or applicable.

I get your point here. That was also what i thought at first after comparing the old template and the new ones that i made. There is obviously some fields that could be adjusted or entirely removed. I'll be more than happy to adjust the template to your liking if you are onboard with idea of using the new template.

I think in the long run we will eventually appreciate the new template. The template could be helpful for us to expect what kind of content should be written in a certain field. And it could also serve as a way to filter out the good issue from the bad issue.

The main motivation behind me creating a new template is this specific issue #2589. I have 2 gripes from that issue:

• Asking for a feature that has been existed for months prior to date of the issue were created.
• Didn't specify the app version, so we don't have any idea whether the poster is on an old version of the app or they just don't realize that the feature has been implemented.

I know the old template has its own perks, but we have to rely on the good faith of the issue submitter to make a proper report. Unfortunately most of the times that isn't the case, often the issue submitter would simply press CTRL+A and backspace and write the issue as they please without following the guidelines properly.

But in the end if this new template isn't your preferred style then feel free to discard the idea. I was planning to ask you before i made this template to see whether you okay with it. But i think it would be more efficient to discuss it after i have opened the PR. I am completely fine if my PR is closed, i made this template mainly for learning purpose.

Anyway, currently the even worse problem is that I simply have way too much to do with PRs alone... I haven't even looked at an issue recently other than clicking links in PRs.

I find it hilarious that there's always a new open PR for every one merged PR. But i see it as a positive thing because there are still new contributors who are willing to submit a PR despite knowing there are 40+ open PR waiting on the line.

Best of luck on your PR review 👍

I think it would be good to add a point to the checklist about the requirement to use English. Some people open issues in other languages ​​🙄

Good suggestion! But first lets see if Helium is onboard with the new template.

[Helium314]

I know the old template has its own perks, but we have to rely on the good faith of the issue submitter to make a proper report. Unfortunately most of the times that isn't the case, often the issue submitter would simply press CTRL+A and backspace and write the issue as they please without following the guidelines properly.

True. Also I sometimes (though rarely) see that people leave the template untouched and only fill the title. This could not happen with your proposed forms.

But i think it would be more efficient to discuss it after i have opened the PR. I am completely fine if my PR is closed, i made this template mainly for learning purpose.

Right, it's certainly good for discussions. Currently I think I'm more in favor than against having forms, so we'd mainly need to do some refinement. Maybe we can reduce the number of fields and checkboxes a little...

Is there a way to test the new templates? Might be more useful than just having a preview, I'd like to try how it feels in the current state compared to fewer input fields and checkboxes.

I find it hilarious that there's always a new open PR for every one merged PR. But i see it as a positive thing because there are still new contributors who are willing to submit a PR despite knowing there are 40+ open PR waiting on the line.

It is frustrating in some way, because I'd like to get it all done (merged or declined), and when I have enough time to get done with a few PRs I often end up with the same amount of open PRs despite all the work...
As you say it's a good sign, and for a bunch of things I really need contributors. But it just... a lot.
Ah well, now I'll be barely available for ~2 weeks, let's see what comes after that.

I think it would be good to add a point to the checklist about the requirement to use English. Some people open issues in other languages ​​🙄

Good suggestion! But first lets see if Helium is onboard with the new template.

Oh, in the post above I wanted to reply to that, not sure why I didn't... Should defintiely be added, if users decide to use a translation tool they can also post the original.

[nugraha-abd]

Maybe we can reduce the number of fields and checkboxes a little...

I'll try to reduce the number of fields, check my updated suggested fields at the bottom of this post. As for the checkboxes in the end those checkboxes are just.. a list of checkboxes. As someone who routinely interact and read the issue we won't really read those checkboxes, all we care about is whether those checkboxes are filled. It's mainly intended for the issue submitter so that they will do what each checklists told them.

Is there a way to test the new templates? Might be more useful than just having a preview, I'd like to try how it feels in the current state compared to fewer input fields and checkboxes.

I am not well versed in how repository works so i can't give an answer to this. If you want to see how the new templates would look like you can take a look at PipePipe's issue template (https://github.com/InfinityLoop1308/PipePipe/issues), which is the source of the inspiration for my written templates.

It is frustrating in some way, because I'd like to get it all done (merged or declined), and when I have enough time to get done with a few PRs I often end up with the same amount of open PRs despite all the work...

You've done a lot, especially considering the amount of time and resource that you have. There's a clear progression since the 3.9 version. Just go at your own pace, what matter the most is you’re enjoying maintaining the app.

Oh, in the post above I wanted to reply to that, not sure why I didn't... Should defintiely be added, if users decide to use a translation tool they can also post the original.

Alright will do, but i am unsure of the best way to phrase it. Could you provide me an example to work on?

Anyway here is my attempt at reducing the number of fields:
bug-report.yml

• Bug Description *
• Expected Behavior * (can be explained in the bug description field)
• Frequency *
• Steps to Reproduce *
• App Version *
• Android version and ROM used *
• Device (not strictly required due to privacy reason)
• Additional Context

feature-request.yml

• Feature Description *
• Use Case * (reduced to the bare minimum. Now only one main field available, which is "feature description")
• Alternative Solution
• App Version *