Issue templates are much nicer in EGit compared to our template
See https://github.com/eclipse-egit/egit/issues/new?assignees=&labels=bug&projects=&template=bug_report.yml
Maybe we should also adjust such a "structured template" for Eclipse platform?
@HeikoKlare, @laeubi, @HannesWell WDYT?
I personally found it occasionally kind of painful to fit into the mold, e.g., when I opened this this where I wondered is it a feature or a bug?
https://github.com/eclipse-egit/egit/issues/60
That being said, I agree that it's interesting. One might provide a choice that basically lets one open a simple issue without a bunch of parts that might be meaningless...
especially mandatory fields are disruptive if they won't matter or can not be answered
As a reporter and a reviewer, I personally dislike such constrained form based template because they're often too constraining and not as efficient. Back when we did chose a text based template for Platform, we decided so to let users have both guidance and freedom to just erase it and report their way if they think is best and so far so good. Moreover, as a "reader" on the issues, the form-based one are not really faster to process, they tend to force user in putting a lost of (potentially useless) information which then require effort to read and then to decide whether to ignore or not.
So let just brainstorm from scratch: what is the issue you see with the current template? How do you think a form would fix it?
Closing as the team prefers the text template. I personally find the EGit nicer but I follow the majority here.
Closing as the team prefers the text template
That is not what we said. I sometimes miss important information and often issues are bad formatted. Maybe templates can help if they are kinda optional.
@mickaelistria and @merks prefer the current way so I closed it
That's not exactly what I said either. 😜
That being said, I agree that it's interesting. One might provide a choice that basically lets one open a simple issue without a bunch of parts that might be meaningless...
I personally found it occasionally kind of painful to fit into the mold,
I don't want to cause you pain.
Guys, if you like a proposal please do say so instead of taking about how painful it can be and how disruptive such fields can be.
Feel free to re-open this issue now that you clearly stated how much you like the suggestion. But let me guess, that is also not what you said.... :-)
I would like to hear a proposal that improves issue quality while maintaining the freedom of choice at least for committers.
And thanks for constantly trying to improve eclipse and workflows @vogella
Thank you for pointing to those structured templates, @vogella. I was not aware of them yet.
Here are some thought/options I see to benefit from them while not forcing anyone into highly constrained forms:
- If I understand correctly, we can provide both structured and unstructured/text-based templates. They can be placed next to each other and could be selected in the issue creation overview (just like you can select between filing a bug, enhancement or vulnerability issue using the according template right now). So we could have the existing "bug" type split up into an form-based bug template and the existing text-based one.
- To avoid a highly contrained form, we might have only a limited number of input fields marked mandatory, just for the absolute essential information (like the "bug description"). I could imagine that for people who are overwhelmed by all the information and categories in the existing template and the difficulty to identify which of them are really "essential", this would make it easier to focus on and provide the mandatory information.
I also see two (rather minor) arguments against these input forms:
- If you have an incomplete state of an issue that you may want to temporarily store locally before submitting it, just copying and storing the contents of a text-based form is much easier than copying the information spread across different input fields.
- If I see correctly, submitting an issue still transforms it into a pure, text-based representation with the structured data only being implicitly represented via the markdown structure. So the result is the same as filling out a text-based template, i.e., there is currently no benefit in processing the issues afterwards (like searching for specific metadata of issues).
Concrete proposal: Give it try. Add a form-based template and see if it used and useful. Keep the existing text template, so that we can still directly use it if the form does not fit. Discuss insights and reevaluate appropriateness/usefulness in some weeks.
Not part of the team, but I do submit and handle issues in other projects. My experience tells me this:
- The fields are there more as a reminder to give that info than to coerce the submitter. Hence, either make them non-mandatory or have a default "irrelevant" (or the like) selection.
- The description/actual/expected trio is often repetitive. Developers tend to know how to write a bug report and these end up just containing the same text with a different phrasing. One box is enough. These are more helpful for end-consumer bug reports that mostly end up being "____ isn't working, please fix" without guidance.