feat(issue template): add more details to feature template

[stephanbcbauer]

Description

Since the feature requester needs more guidance about the feature description/specification, this PR adds more attributes/information to the feature template.

This information was also needed to measure the definition of ready ⇾ ready refined and in the end definition of done.

Pre-review checks

Please ensure to do as many of the following checks as possible, before asking for committer review:

• DEPENDENCIES are up-to-date. Dash license tool. Committers can open IP issues for restricted libs.
• Copyright and license header are present on all affected files

[SebastianBezold]

I wouldn't mind merging the PR like it is. Maybe with a reconsideration of how links between issues are done.

But I also have a slightly different idea. I heared from the OpenTofu project, that the split the feature request part in two. See their contribution guide First, a very simple template can be use, so it is possible for everyone to create features. These proposals are discussed on that simple level, and when it is agreed to work on it, a RFC is created, stating details about UX, DX, Architecture and so on.

I think that could keep the barrier to entry lower. What do you think @stephanbcbauer

[SebastianBezold]

I think the link should be made from the product specific repos to this one here. Otherwise you always have to edit the description, as soon as a new "subtask" is created. Linking it this way, will also show the status of the issue (open or closed. merged for PRs). With a simple check list, you always need to manually tick them

[FaGru3n]

Maybe we could add this information within the info part like

<!-- 
- [ ] Criteria 1
- [ ] Criteria 2
- [ ] Criteria 3
-->

[FaGru3n]

Hi @stephanbcbauer overall cool idea but i also share the opinion from sebastian to make it more transparent within the issue template that some further steps should be planned in the product repos and mention the overall issue itself.

[FaGru3n]

Suggested change

	## Impact/Dependencies
	## Impact/ Dependencies

[mhellmeier]

I would not accept this, since slashes are always used without spacings.

There are usually no spaces either before or after a slash. According to New Hart's Rules: The Oxford Style Guide, a slash is usually written without spacing on either side when it connects single words, letters or symbols.

Source: https://en.wikipedia.org/wiki/Slash_(punctuation)

[FaGru3n]

Maybe we could add this information within the info part like

<!-- 
- [ ] Criteria 1
- [ ] Criteria 2
- [ ] Criteria 3
-->

[mabige]

Question: How to deal with this checkbox, in case that more than one person is willing to contribute - which is hopefully the standard case in the future :-)

[FaGru3n]

I guess depends on the working model, but if the person who wrote the issue is willing to contribute and want to add more people to this issue ... then the writer can easily change the description within the template "we are willing to contribute"

[mhellmeier]

I added a baseline set of checks from the Architecture Management Committee.

[mhellmeier]

Suggested change

	### Architecture Management Committee Check
	<!--
	The Architecture Management Committee monitors and controls the overarching architecture. It is essential that all applications and documentations follows a baseline set of standards and guidelines. These small checks ensure that the proposed change does not compromise our general principles.
	-->
	The following items are ensured (answer: yes) after this issue is implemented:
	- [ ] **Architecture:** This issue is compliant with the [overarching architecture](https://eclipse-tractusx.github.io/docs/tutorials/e2e/inform/architecture) and its existing standards and protocols
	- [ ] **Data Sovereignty:** All data sharing activities across company boundaries follow the [Dataspace Protocol](https://docs.internationaldataspaces.org/dataspace-protocol/overview/readme) via a compliant Connector (like the [tractusx-edc](https://github.com/eclipse-tractusx/tractusx-edc) or similar, see [Connector KIT](https://eclipse-tractusx.github.io/docs-kits/next/category/connector-kit))
	- [ ] **Interoperability:** Digital Twins are used (compliant to the [Digital Twin KIT](https://eclipse-tractusx.github.io/docs-kits/next/category/digital-twin-kit) and the [Industry Core KIT](https://eclipse-tractusx.github.io/docs-kits/next/category/industry-core-kit))
	- [ ] **Data Format:** The data model is based on a [published Semantic Model](https://github.com/eclipse-tractusx/sldt-semantic-models)
	**Justification:** _(Only needs to be filled out if at lease one checkbox item could not be answered with "yes")_