mariha
commented
3 years ago Agree, it's confusing to have the two and none of them describes what exactly we expect from the person who reports an issue.
For me a bare minimum would be to have a problem to be solved template only which would describe the C4 rationale for it. Most people are used to have defects and feature requests so I think it would be good to explain why we chose not to.
I find it hard to rephrase every work item that I feel like needs to be done to a problem. It seems to me that especially at the beginning projects are driven more by visionary and creative ideas than by reactive defects, bugs and patches. And those ideas don't fit into problems that naturally as other issues, but let's try and see how it works.
I'd consider:
- keeping bug report and feature request categories and at the beginning of them write that we'd like everything to be stated as a problem to be solved and potential solution(s).
- marking bug or feature templates as "deprecated" for a while instead of removing them. They are not bad, and I guess there was a reason why someone put them in place. They have some helpful guidelines and a check list is someone didn't know what may be relevant.
- have problem statement and other category, just in case, to be more welcome to things that don't fit naturally into "problems"
- have problems only and no other choice to simplify life and a number of options :).
When creating an issue, Feature Request and Bug Report templates are shown but neither is necessary if we're limiting issues to problems per C4.