#1199: Create templates for PR and issues

[julia-cap]

Fixes #1199

Changes made:

• created directory for issue templates
• created templates for Feature, Bug and Security Vulnerability
• created one template for PR

[coveralls]

Pull Request Test Coverage Report for Build 15041965121

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• 1 unchanged line in 1 file lost coverage.
• Overall coverage decreased (-0.01%) to 67.699%

---

Files with Coverage Reduction	New Missed Lines	%
com/devonfw/tools/ide/tool/ide/IdeToolCommandlet.java	1	77.59%

Totals
Change from base Build 15041251660:	-0.01%
Covered Lines:	7976
Relevant Lines:	11375

---

💛 - Coveralls

[hohwille]

Thanks for updating to main so I now could test the PR template live on github.
Can you even edit the settings of your fork to allow issue creation so we can also test the issue templates?

Some early review feedback about the PR template (obviously some things are already clear to you since this PR is still in draft mode):

• there are several markdown syntax issues. While GitHub gives the freedom to choose markup syntax for files in git or wiki, in comments or PR templates only markdown is supported. We decided for AsciiDoc since it is much more powerful and intuitive to use (e.g. link syntax in MD sucks) but for comments and such templates we have stick with markdown so unfortunately in such situations you need to master both.
• we need to pay attention that we do not go from one extreme to the other. Currently we do not have a PR template and everything is quite lax and pragmatic. If we come up with an over-complex submission matrix, developers may be overwhelmed and might even stop taking it serious and go trough all checks since it is too tedious.
• IMHO we should stick with a simple checkbox instead of an additional N/A column. For some points we can just change the description easily so that I can check it in every case where I did my job properly. For some other points, that are violated (N/A) rarely the user could simply edit and strike through the aspect. For commandlets we can create a separate block/table that can be removed or the developer could choose between no commandlet added [x] or the table of commandlet checks.
• We should also kick out all rules that are already checked automatically. I do not see the value in Build is successful and tests pass when running mvn test (or even better mvn clean test) or especially All GitHub checks have passed since we already have an automated CI build that gets red if he missed out this point - further this can change with every commit and I can guarantee that no developer will uncheck a checkbox after an updating commit. Also I would remove the Milestones topic and would question Changes are covered by unit tests together with the team.
• So the DoD is also a documentation explaining things for new developers, while the PR template IMHO should focus on the key aspects.

[hohwille]

@julia-cap thank you very much. This is really great progress. 👍
I could not find anything wrong with the security label (no typo, syntax issue, etc.).
Let us just merge and then we can further improve (I would also consider removing the help texts point since this is automatically checked by JUnit).

[julia-cap]

@julia-cap thank you very much. This is really great progress. 👍 I could not find anything wrong with the security label (no typo, syntax issue, etc.). Let us just merge and then we can further improve (I would also consider removing the help texts point since this is automatically checked by JUnit).

Sure, let's keep it simple and short ;) I will remove the line about help texts.