RFC Specify issues for better design choices #98

New Issue

GiteaMirror · 2026-02-17T11:45:31-06:00

GiteaMirror commented

2026-02-17 11:45:31 -06:00

Originally created by @matu3ba on GitHub (Apr 21, 2020).

I do very much like your choices for commits, but I am missing a convention/specification for issues.
Below is a combination of bug/rfc that is common in project structures open for comment.

Reason: estimation of cost (maintainability vs gain) is underspecified for technical reasoning in the merge commit

Context: Merge commits tell you nothing about the technical basis of the decision to the code. Hence you leave the code design part completely out and end up making poor choices or leave others to make it unnecessary hard to learn from your design mistakes.

Please provide feedback on the idea.


bug/rfc: description

expect: outcome description

related: none/#issuenumber

code: input
---
code/steps
---

expect: output
---
result
---

kernel: win10/win7/linux4.4/linux5.7/mac10.0/mac10.15

version: `program --version`/`git rev-parse HEAD`

interaction: none/program list

context: additional setup/run inside virtual machine with special libraries etc/links, text and further literature
behavior of similar programs

perf: impact

performance

usability

maintainability

Originally created by @matu3ba on GitHub (Apr 21, 2020). I do very much like your choices for commits, but I am missing a convention/specification for issues. Below is a combination of bug/rfc that is common in project structures open for comment. Reason: estimation of cost (maintainability vs gain) is underspecified for technical reasoning in the merge commit Context: Merge commits tell you nothing about the technical basis of the decision to the code. Hence you leave the code design part completely out and end up making poor choices or leave others to make it unnecessary hard to learn from your design mistakes. Please provide feedback on the idea. ``` bug/rfc: description expect: outcome description related: none/#issuenumber code: input --- code/steps --- expect: output --- result --- kernel: win10/win7/linux4.4/linux5.7/mac10.0/mac10.15 version: `program --version`/`git rev-parse HEAD` interaction: none/program list context: additional setup/run inside virtual machine with special libraries etc/links, text and further literature behavior of similar programs perf: impact performance usability maintainability ```

GiteaMirror closed this issue

2026-02-17 11:45:31 -06:00

GiteaMirror commented

2026-02-17 11:45:32 -06:00

@matu3ba commented on GitHub (Apr 21, 2020):

Aside I noticed you have no fields for the meaning usability and maintainability, which are essential to code bases.

@matu3ba commented on GitHub (Apr 21, 2020): Aside I noticed you have no fields for the meaning `usability` and `maintainability`, which are essential to code bases.

GiteaMirror commented

2026-02-17 11:45:33 -06:00

@damianopetrungaro commented on GitHub (Jun 8, 2020):

Hey @matu3ba I'd suggest you create a new project for that since conventional commits have as main focus fixing commits and not PR or bugs.

Sorry for not being able to help you on that <3

@damianopetrungaro commented on GitHub (Jun 8, 2020): Hey @matu3ba I'd suggest you create a new project for that since conventional commits have as main focus fixing commits and not PR or bugs. Sorry for not being able to help you on that <3

GiteaMirror referenced this issue

2026-02-17 11:57:34 -06:00

[PR #102] [MERGED] fix: Remove spec ambiguity between body and footer #288

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/conventionalcommits.org#98