Which Component Label is missing?

[FaGru3n]

Currently we have the following "component"-labels for this repository

• edc
• portal
• irs
• country risk
• golden record
• miw
• trace-x

In my opinon we should be very thrifty with adding new lables to not confuse everyone.
Idea for Labels: https://github.com/eclipse-tractusx/sig-release#issue-structure

But at least i think we have some missing components that are not represented as a component label.

Do you have an idea which components are missing ? e.g (sde, puris, ... )

• sde
• puris
• ...

Or should we take all component repositories which are currently shown in the Release Guidelines Checks Board

[FaGru3n]

FYI: @RolaH1t @giterrific @mabige @danielmiehle @Siegfriedk @SebastianBezold

[drcgjung]

+1 for "knowledge-agents" (represents "Knowledge Agent" component, "Knowledge Agent KIT" and "knowledge-agents-edc", "knowledge-agents", and "knowledge-agents-aas-bridge" repositories)

I would also opt for some kind of intersection/mediation between what is currently defined as
"product" (release guidelines checks board)
"kit" (https://eclipse-tractusx.github.io/developer) or
"component" (quality/release process)
and not individual repos (those can be already easily associated and filtered from any issue).

IMHO, they could share a common color (it represents always the affected/realising team).

[RolaH1t]

The DELTA to the currently known Release Scope is:
SDE
Managed Service Orchestrator
Knowledge Agent
SD Factory
Digital Twin Registry
Discovery Finder
Discovery Service
Semantic Hub
Digital Product Pass
...and in addition for the KITs...
Business Partner KIT
Connector KIT
Traceability KIT
BT RUL KIT
BT HI KIT
BT MDP KIT
Eco Pass KIT
Circularity KIT
Quality KIT
OSim KIT
PCF KIT
Digital Twin KIT
Knowledge Agent KIT
Modular Production KIT
Data Governance KIT

[mhellmeier]

Do you have an idea which components are missing ? e.g (sde, puris, ... )

• sde
• puris
• ...

First of all: What is the definition of a "component"? Is it like a service used by different use cases inside Catena-X? In such a case, things like the EDC, MIW etc. should be components, but not use case-specific applications like PURIS.

PURIS main contact person: @tom-rm-meyer-ISST

[FaGru3n]

Hi @mhellmeier i guess we mean the same with different wording "component" = core "services"

and thanks for clarification with Puris...

[FaGru3n]

Hi all,
added together with @RolaH1t the following labels.

Please checkout https://github.com/eclipse-tractusx/sig-release/labels and if some further things are missing feel free to state out here.

[stephanbcbauer]

@FaGru3n during the refinement there was often the question of what to do with features where further discussions or decisions are needed. For my felling they should still stay in input (of course) but maybe we can add a triage label just to make sure ... "here is definitely something to discuss/decide"??

[FaGru3n]

Hi @stephanbcbauer,

sure also @mabige want to have a marker like this

https://github.com/eclipse-tractusx/sig-release/labels?q=open

But in general open disscussions can held in the Feature / Bug Issues itself, then also all paricipants for this feature will be informed and also can discuss. It also makes it more visable and transparent why some decision was taken. For a general decision i would use the mailing list or a poll in the discussion section within our 'sig-release' repo
https://github.com/eclipse-tractusx/sig-release/discussions/categories/polls

[stephanbcbauer]

@FaGru3n thx. Helps a lot. Will spread it :)

[enzio-bot]

Hello,
Today we had a situation in a discussion where we agreed that the item was a 'nice to have' or an enhancement as we verbally discussed priority and dependencies.

I foresee the challenge is that in the future, we will forget about this decision or have a different audience, and we would like to recognise in the future that the GitHub issue is an enhancement of sort (to not have the same discussion again like we had today). Is there a way to better indicate this or is there a type of supported concept/model/framework we could refer to configure issues with labels etc correctly?

Perhaps a documentation item where we could record and improve over time? I'd be glad to help if required, but need advice on how to solve such problems if I am to help.

[FaGru3n]

Hi @enzio-bot,

i don´t know if i understand it corretly... You want a framework or a documentation page how to label, discuss correctly?

that the item was a 'nice to have'

Which item do you mean?

[enzio-bot]

Hi @FaGru3n,

Please see below explanation, hopefully this answers your question. I've highlighted the two differences as it was actually two different questions.

1. The specific question was how do we record a GitHub issue as an enhancement which might indicate low priority for current and future backlog prioritisation meetings? Is there a label, or attribute we can set to quickly ascertain this without having to read a description or interpret the requirement?
2. The larger, more generic and big picture question or requirement is - is there a section in some documentation in which the correct procedure for creation of GitHub issues is documented for GitHub novices or people who mostly use Jira?

Motivation:
The idea is to also help the developers and FOSS community understand GitHub issues that are created as the issue creator (often perhaps a BRE/PO or other) probably understands the scope, but not the other readers (unless asking the creator for further context).

Secondly, I believe it would assist using GitHub by means of structured data if these attributes were defined and were searchable, filterable etc.

Perhaps the documentation is not explicitly necessary, but I assumed that is the a good way how to record this info and could also be a reference point for now and future new joiners.

What do you think? If you think these items aren't an issue, then please let me know.

[FaGru3n]

Thanks to you @enzio-bot for the explaination.

to 1.
Currently there are no prioritisation things (labels / stati / sorting ) within this sig-release repository, because in this repo the features / bugs / release tracking issues should be used as showcase / roadmap for the public world, what´s comming in the next releases. But in general for team / component repo´s you / we could add easily some "prio" aspects for the issue tracking.
For Enhancements i guess it is clear, if you plan a new Feature that this is a in some way an enhancement.

Lables you can find here: https://github.com/eclipse-tractusx/sig-release/labels
this is also relevant for the motivation:

The idea is to also help the developers and FOSS community understand GitHub issues that are created as the issue creator (often perhaps a BRE/PO or other) probably understands the scope

to 2.
We have already docs to the wiki and the README.md in the sig-release repository for "beginners" and on our docusaurus-web-page.

• https://github.com/eclipse-tractusx/sig-release#readme
• https://github.com/eclipse-tractusx/sig-release/wiki
• https://eclipse-tractusx.github.io/docs/oss/getting-started

to Motivation:

Secondly, I believe it would assist using GitHub by means of structured data if these attributes were defined and were searchable, filterable etc.

The current labels are already searchable, filterable 😉
A: Either on the Release Planning Board

B: or on the issue list in the repository itself

also possible:
https://github.com/eclipse-tractusx/sig-release/issues?q=is%3Aopen+is%3Aissue+label%3A%22country+risk%22
see: https://docs.github.com/en/search-github/searching-on-github/searching-issues-and-pull-requests

And also for documentation rules and guides you can also have a look into our Eclipse Handbook.
https://www.eclipse.org/projects/handbook/

[SebastianBezold]

HI @enzio-bot,
just a short, more general input from my side.

Indicating things like "low-prio" or "enhancement" on GitHub issues is almost always done via labels, so I would prefer, if we do it in eclipse-tractusx aswell.
Actually, we as community can create any label, that we think is useful to support our processes. If you suggest, that enhancement as an indicator is useful, we can add that. Just keep in mind, that a lot of labels can also be overwhelming and finding the right label to properly indicate your topic will become harder.

To you question regarding the "correct way of creating issues":
Describing, what "correct" means is not possible in my opinion. But there are guiding principles:

a) Assume, your issues will be read by people that do not have all context, so either explain it, or link to further info (preferred)
b) Communicate changes transparently. So instead of always editing the description on issues, maybe add comments instead, so others can follow the thought process behind feature discussions (also valuable documentation)

In general, there is not a lot, that you can do wrong. Overthinking the process might actually be the only bad thing :).
If you need help on how to work with GitHub itself, we are also happy to do a small crash-course/onboarding session

[enzio-bot]

Thank you for the replies @FaGru3n and @SebastianBezold. I have a better understanding now, I'll go through the items and create labels in the component repos if required. I'll also review those links Fabian sent. :)

[FaGru3n]

For now i would close the discussion, and if labels have to created or changed we could open a new discussion