Skip to content

Conversation

@a-zw
Copy link
Contributor

@a-zw a-zw commented Oct 28, 2025

Since they reflect decisions made at a specific time, it is often very informative when that happened.

Since they reflect decisions made at a specific time, it is often very informative when that happened.
@github-actions
Copy link

The created documentation from the pull request is available at: docu-html

Copy link
Contributor

@masc2023 masc2023 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will be discussed in the next community meeting

:id: dec_rec__<Platform|Feature|Component>__<Title>
:status: <proposed|accepted|deprecated|rejected|superseded>
:affects: <link>
:date: <YYYY-MM-DD>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Compare here, date is part of commit history e.g. https://github.com/eclipse-score/score/commits/main/docs/design_decisions/DR-003-infra.md, if there is a way to put it in automatically, fine for me.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Git history tells you when a file is modified that might be more recent than the last status change. For example, consider a mere layout change.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For reference, DR-004 just got merged. In contrast to 001 to 003, it is much closer to the process-provided template. I put the date into the content there.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am against this documentation of information that we already get provided by version management. If it is about a status change (which is documented in one line) you can find out via git blame. If we do this in this kind of documentation, this would in my opinion invalidate our argumentation that for documents we do not need to document author, reviewer, version, date because this all is in github already available. If you want to automatize this setting of the date, I would be fine, but is it really worth the effort?

Copy link
Contributor

@aschemmel-tech aschemmel-tech left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not support this

:id: dec_rec__<Platform|Feature|Component>__<Title>
:status: <proposed|accepted|deprecated|rejected|superseded>
:affects: <link>
:date: <YYYY-MM-DD>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am against this documentation of information that we already get provided by version management. If it is about a status change (which is documented in one line) you can find out via git blame. If we do this in this kind of documentation, this would in my opinion invalidate our argumentation that for documents we do not need to document author, reviewer, version, date because this all is in github already available. If you want to automatize this setting of the date, I would be fine, but is it really worth the effort?

@masc2023
Copy link
Contributor

masc2023 commented Nov 4, 2025

@a-zw , Process Community do not agree to add this new attribute, any change can be seen in the commit history (including date, status and which code changed), otherwise we would also need to discuss, why it is only for DR documents and not for all others.

@masc2023 masc2023 closed this Nov 4, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants