Hi Michael, see my comments inline:
On Thu, Jun 4, 2026 at 4:10 PM Michael Brohl <[email protected]> wrote: > [...] > The contributing documentation you provided in [4] is clear and > understandable and I like that. But it seems to move away from the Jira > based process and I see some drawbacks in it. > > For topics which need conceptual work, discussions or structure to split > bigger tasks into subtasks (like in [5] or maybe upcoming bigger tasks > to refactor the framework), an issue based approach seems to fit better > in my view. I fear only having pull requests will make it harder to > manage those tasks. I agree with this. This is also stated in my mail and at the beginning of CONTRIBUTING.md: "For larger changes, opening an issue or discussion first is recommended > but not required." We could suppress "but not required" in order to convey the importance of Jira in these specific cases. If I understand it right, having the Jira issue > number in the pull request title is needed to make them automatically > linked together, right? > That's correct. What I am proposing is to keep the existing message template (with some minor modifications), which includes an optional Jira ticket number, as the template for pull request, not for commit messages. Commit messages should instead follow the open and more widely adopted convention of: TITLE (in imperative form, no full stop, no references to external resources such as Jira tickets) OPTIONAL PARAGRAPH (after a blank line, with more descriptive content about the commit) > > The commit message template was a step forward to have more formal > commit messages with the idea to be able to parse them and use them as > base information for the blog. It would be great if we find a solution > where we can still compile changelogs, release notes etc. with reference > to more detailed information like in Jira or pull requests. > The solution I am proposing would still allow us to compile changelogs automatically: however the source data will be the titles of the pull requests (that may contain Jira ticket ids) rather than the commit messages. I think that this is a more natural approach because pull requests are less granular than commit messages and better represent the concept of "features". Moreover, basing release notes on pull requests rather than Jira is preferable because the release notes would capture all the contributions, not only those with a Jira ticket. I hope this clarifies my proposal, Jacopo
