At first I thought it would be better to do it the other way around, link to forge or a dynamically generated page on forger with the id from the commit message.
But the more I think about it and read the other comments, this proposal is the one thing we can do right now with the tools we already have. Everything else will be just put on some todo list and who knows when people will have the time for it?
practical suggestion to move this forward (because I really like the initial idea):
Don’t even try to make this 100% accurate or complete. Communicate it to have not authoritative character (like author of a book) but more something like a dedication in a book where you write (I want to thank the following people who contributed to my work: my professor, my proofreading spouse and my genetically enhanced parrot Dave)
It’s not just the responsibility of the merger to at least try to make this complete, it’s the responsibility of the issue opener, the patcher, everybody else watching the issue or the review and the people who contributed to try to make this list complete. So this will not result in chaos with everyone committing changes, the patcher is the person responsible to coordinate this until the patch is merged. Clear guidance for this (as well as suggested tags and the example above) can be put in the Contribution Guide.
Give this a trial run and see if it pans out.
What I like about this whole idea: You don’t just have the final result in the commit message. What is even more important: You get more people to think about who else contributed to something and communicate about it.
Markus pointed out that the Gerrit metadata should be in the last block (footer). You could easily change the order in your suggestion to comply with this.
I am totally in for this. I do not understand the discussion about the additional effort. As already pointed out, quite often we have simple patches where just 1 to 2 people (beside the reviewers) are involved. If you are working on a bigger patch/ initiative than you normally know the people who are involved. Compared to the time we spend on the patch, gathering the needed information is time-wise next to nothing. It would be a great opportunity and I am looking forward to the new possibilities and the gamification. Great idea!
As Björn mentions the change would not be that much extra work compared to writing a patch. For me mentioning the people involved, who are normally invisible in a patch, is a great way to visualize contribution.
To make it easier to maintain the people, everyone should add himself. for the non tech people like the concept or UX people, the author of a patch can add this people in the first step, which is not a big deal.
Everyone who work on the patch is responsible to add himself.
Compared to add all contributors to the forge ticket, what exactly is the benefit of having them in the commit message, especially if the goal is to extract the information and prominently publish it?
The benefit of adding them to the ticket would be, that I could add some people even now, giving them credit for what was merged already.
Post reviews could be credited, it is less error prone as well, as missing names could be added at any point in time.
Regarding „the overhead“:
Of course any effort to become more inclusive and thankful is absolutely worth it.
That said, my intention is to avoid unnecessary overhead wherever possible.
E.g. the requirement of having a forge ticket for every change request, more often than not leads to duplicated information or forge tickets with having less info than the commit message.
If this proposal isn’t about adding a new requirement (which I read from changing the hook), but about the possibility to add diverse contributors where it makes sense I’m fine of course.
I still think bugtracker would make more sense for that, but I would also be fine with commit messages, if there are reasons to do so.
That said, I think the creator of a change should be responsible for adding such information because it will be the person most likely knowing the people involved, more so as the reviewers or mergers at least.
In my humble opinion, the commit message is the wrong place for mentioning reviewers, because it should contain information on the changes in code, not some meta information about what has lead to this commit and who was responsible for what. Imo it’s already overhead to mention related ticket ids, besides the one the commit is meant to be for. These meta information should not be contained in the versioning system, but in the issue tracker, that also contains discussions on how to reproduce an issue or further links and downloads for the task at hand.
It could also lead to people asking random contributors about the implemented changes, rather than the one who actually did the commit in the first place. This could lead to confusion on whom to ask if the commit changed something one must understand to revert or fix it, if it broke.
If it’s too much hassle to maintain the list in the commit message or for some other reasons unwise, perhaps the list of contributers can be retrieved from Gerrit and possibly the related Forge ticket (at least the reporter). Every release could from now on have a section called contributors built automatically with the mentioned list.
Missing would only be folks that contribute but for some reason are neither active on Forge and Gerrit.
Having the contributor list in the release notes doesn’t have the problem of forgotten people. Simply add them after the ticket has been closed - but of course before the release.
Ok, it’s unorthodox to put some metadata in the commit message. I agree. Do not duplicate information. Yes.
But asking the people who want to put in in Forge: How exactly do you want do put additional machine readable information in the Forge issue? Or if you don’t extract it but use the issue page as reference, how do you want to achieve it that the issue page looks like something someone would actually want to look at? Seriously.
Maybe someone could do a Mockup for this. Might be helpful.
What you can do (I guess) is extract everyone who interacted with the ticket (made comments etc.). But then you only have the person name but not what they did. You can’t do what the initial suggestion is trying to do with Forge right now, can you?
I think that is why it was suggested to do it this way.
I also like the idea, and at least for reviewers it should be easy to add them, as Gerrit has that information ready.
As for where to store the information: let’s stick to Gerrit/commit messages for now, as there is a quasi-standard for that, while using Forge would create some more issues (no pun intended).
If we realize that we need post-merge attribution etc., the info is easy to parse from the commit history, can be added to $futureToolForThis and then we can let people “claim” a commit (= “I worked on this doing task X”).