Add GitHub issue form templates

[leandro-lucarella-frequenz]

Add a form for reporting bugs and requesting new features. Also configures the new issue screen to show both templates plus a quick access to ask questions in the Discussions forum.

I'm not so sure about the version:xxx labels (and the form entry). I think for this repo it might be overkill but eventually for other repos it might be useful, specially when bug reports come from external users, is a good way to make users think about which version are they using (and thus check if it is the latest one).

If this becomes too annoying (as with all the latest PRs), we can change it.

For more info on GitHub issue forms: https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/syntax-for-issue-forms

[tiyash-basu-frequenz]

A few grammatical fixes to address here and there, but looks good overall.

[leandro-lucarella-frequenz]

Thanks for all the corrections! It would have been awesome if you provided them in form of change suggestions! 😄 (me lazy?)

All done! I'm also trying out the approach of adding new commits after review comments instead of amending the existing commits. This (ideally) should make it easier to review a PR after it was modified based on comments in a review ♾️. If you hate it I can amend the existing commit too.

[tiyash-basu-frequenz]

Sorry, one last nitpick :)

I like the idea of using suggestions!

[tiyash-basu-frequenz]

I'm also trying out the approach of adding new commits after review comments instead of amending the existing commits. This (ideally) should make it easier to review a PR after it was modified based on comments in a review

I you overwrite the commits in a PR, then github shows you the diff from the force-push. It may not be as granular as individual commits, but it gets the job done for me. So, for correcting small mistakes like typos and such, I'd personally prefer to overwrite existing commits, in order to keep the commit history clean. :)

[sahas-subramanian-frequenz]

I'm also trying out the approach of adding new commits after review comments instead of amending the existing commits. This (ideally) should make it easier to review a PR after it was modified based on comments in a review infinity. If you hate it I can amend the existing commit too.

this is what fixup commits are for. They make it easy to review, and can be squashed before merging.

[leandro-lucarella-frequenz]

I you overwrite the commits in a PR, then github shows you the diff from the force-push. It may not be as granular as individual commits, but it gets the job done for me. So, for correcting small mistakes like typos and such, I'd personally prefer to overwrite existing commits, in order to keep the commit history clean. :)

I think is a shift of workflow, you know pretty well I used to work like that and I really liked, now I tried this way and I think it has a few advantages. Besides GitHub being better at it (for example links to old reviews break if you amend and force push, and getting better tracking of what you already reviewed and what you didn't), I'm not sure what you want a clean history for. You are even hiding the history that way (for example, if you want to see in the git history how much effort a change took, it is very deceiving if you see only one perfect commit rather 3 or 4 with some subtle fixes that weren't obvious at first). The history is I wrote something, you saw some problems and suggested some changes, and I did those changes. If you want a summarized view of the history, you can use git log --merges and you only get the merges which tells the summary.

this is what fixup commits are for. They make it easy to review, and can be squashed before merging.

I would argue that that's one way fixup commits can be used. It would be much better if GitHub had an option to enable --autosquash when merging, otherwise I have to do it manually (same with applying review suggestions). But again, that doesn't solve the problem of losing the history of how a change evolved thanks to the feedback from peers.

But is OK, I was also used to do rebases and was quite convinced it was the best (remember I even wrote a CLI tool to do "rebase merges" before GitHub supported it 😆), and I know it takes time to do a switch, so I'm fine with continuing with it too :)

New suggestion applied. I will squash now.

[sahas-subramanian-frequenz]

But again, that doesn't solve the problem of losing the history of how a change evolved thanks to the feedback from peers.

I agree, and if we have external contributors, it will be hard to convince them to keep commit history beautiful. I'm glad we have merge commits now so what people do in their branches becomes less important.

[tiyash-basu-frequenz]

I think it really depends on the preferences of the contributors, whether they want to squash commits or not. The reason is that we can't control what rules contributors have set for their branches, and everyone will have a different definition of a clean or accurate history.

So, I am happy with either approach.

[tiyash-basu-frequenz]

LGTM!

[andrew-stevenson-frequenz]

Just pednaticness

[andrew-stevenson-frequenz]

Suggested change

	Please tell us what's missing or what could be done better or easier.
	Please tell us what's missing or what could be done better or more easily.

[andrew-stevenson-frequenz]

Suggested change

	placeholder: What's missing or what could be done better or easier.
	placeholder: What's missing or what could be done better or more easily.

[andrew-stevenson-frequenz]

Suggested change

	Please tell us how do you think the needs above can be fulfilled. Only
	Please tell us how you think the needs above can be fulfilled. Only

[andrew-stevenson-frequenz]

Suggested change

	Please tell us if you tried any alternatives or workarounds for those
	Please tell us if you tried any alternatives or workarounds for these

[andrew-stevenson-frequenz]

Suggested change

	use cases and how (un)useful they are.
	use cases and how (un)useful they were.

[andrew-stevenson-frequenz]

Suggested change

	Any alternatives or workarounds for those use cases and how (un)useful
	Any alternatives or workarounds for these use cases and how (un)useful

[andrew-stevenson-frequenz]

Suggested change

	they are.
	they were.

[andrew-stevenson-frequenz]

Suggested change

	Please add any addition information here, screenshots, diagrams, etc.
	Please add any additional information here - screenshots, diagrams, etc.

[andrew-stevenson-frequenz]

Suggested change

	placeholder: Any addition information here, screenshots, diagrams, etc.
	placeholder: Any additional information here - screenshots, diagrams, etc.