Hi again Adam! First of all, thanks for all the wisdom here. I learned a lot from what you said, especially about vendor lock-in. I understand now that we want to keep the project flexible for future-proofing reasons.
I also agree with everyone that Commit Trailers sound like a great idea. CoauthoredBy, ReviewedBy, ReportedBy, and TestedBy are important for credit purposes. We could also use DesignedBy, as this is not really available on Github or JIRA. Having this information would definitely help in reducing our reliance on these APIs that could go down anytime. In terms of naming scheme, I believe Github API gives us the entire commit message, which means we can pick and choose any trailer names we would like. I think we can honestly just go with something simple here, as long as it's consistent. Finally, for template schemes, you definitely know better than I do here. To add my 2 cents though, I think having some structure like problem::: solution might help descriptions flow more naturally. Just an idea. Here's an example. Could you let me know what you think? Fineract-0000: <Brief Description> Problem::: Solution Next Problem::: Next Solution Next Problem::: Next Solution < Additional Metadata > CoAuthoredBy: First Last ReviewedBy: First Last TestedBy: First Last DesignedBy: First Last ReportedBy: First Last On Mon, Feb 2, 2026 at 10:52 PM Mohammed Saifulhuq < [email protected]> wrote: > Re: one commit per PR > > Hi everyone, > > Adding my thoughts as a recent contributor. > > I strongly support the *"One Commit per PR"* convention. From a > maintainability standpoint, having a linear, clean history makes git > bisect and reverting bad commits significantly easier in the future. > > Regarding crediting multiple contributors: I agree with Adam M and Arnav > that *Git Trailers* are the standard solution here. Specifically, using > the standard Co-authored-by: Name <email> trailer is natively supported > by GitHub and automatically links the commit to that user's profile in the > UI. This solves the credit issue without polluting the commit log with > intermediate "fix" commits. > > +1 for documenting this clearly in CONTRIBUTING.md with a template for > the trailers. > > Regards, Mohammed Saifulhuq > > > On Tue, Feb 3, 2026 at 9:12 AM Arnav Patil <[email protected]> wrote: > >> Hi everyone, >> >> Thanks for the detailed discussion — this thread has been really helpful, >> especially for contributors who are still learning the Fineract workflow. >> >> From a contributor’s perspective, keeping one commit per PR as the >> default feels like a good baseline: it keeps history readable and reduces >> back-and-forth during reviews. At the same time, I agree with the concern >> that credit shouldn’t be lost when more than one person meaningfully >> contributes. >> >> Using commit message trailers (e.g. Coauthored-by:, Reviewedby:, >> Testedby:) seems like a practical middle ground: >> >> - >> >> preserves a clean commit history, >> - >> >> avoids extra GitHub-specific enforcement, >> - >> >> and still allows proper acknowledgment of everyone involved. >> >> I also strongly agree that whatever convention we settle on should be >> clearly documented (CONTRIBUTING.md / PR template), ideally with simple >> examples for newer contributors (e.g. when to squash, how to add trailers). >> >> On Tue, Feb 3, 2026 at 8:17 AM Aman Mittal <[email protected]> >> wrote: >> >>> Hi Adam M. >>> >>> Thanks for opening discussion on dev list, Let me clarify my intention >>> for creating this ticket. >>> >>> I noticed that maintainers have to notify new contributors everytime to >>> squash their commits in PR. >>> >>> I think that. This can be automated. >>> I have thought 2 different implementation based on this. >>> >>> 1. General GA check in PR open. This will notify the user to squash >>> commits meanwhile I also noticed 2 commits merged in some PRs (so changed >>> it into per person commit) >>> >>> 2. Another way this can be implemented via stale bot like check. Which >>> automatically comments on every PR that not following convention. >>> >>> And based on what discussed here feel free to change the ticket >>> requirement after conclusion. >>> >>> Regards, >>> Aman Mittal >>> >>> >>> >>> >>> On Tue, 3 Feb, 2026, 7:17 am Adam Monsen, <[email protected]> wrote: >>> >>>> Hi Edward! Thanks for your comments. Replies inline, below. >>>> >>>> I did a bit of research... >>>> >>>> >>>> Fascinating. I've never used autosquash and I don't understand that >>>> example. Based on the git-rebase(1) manpage it seems to be a way to avoid >>>> an interactive rebase with carefully worded commit messages. Personally I'm >>>> a big fan of interactive rebase so I probably wouldn't use it. I guess >>>> folks can squash however they want. >>>> >>>> The multiple contributors does complicate the FINERACT-2462 >>>>> implementation... >>>> >>>> >>>> Thanks for this. I'm wary of adding more dependencies on github. I've >>>> seen this codebase migrate between version control systems (from subversion >>>> to git) and between code collaboration platforms (sourceforge to github), >>>> and I imagine it'll happen again someday. Vendor lock-in complicates >>>> migrations. I'm also wary of adding any friction to contributors trying to >>>> submit patches (e.g. confirming correct email is being used). >>>> >>>> I was wondering if recording all contributors is something we can >>>>> implement automatically... >>>> >>>> >>>> I like this idea. Maybe it would work with the "trailers" idea? I >>>> think, before we automate, the important first step here is reviewing what >>>> data we currently have and gathering the new data we want while adding as >>>> little friction as possible, and with just enough structure that we can >>>> pull out something useful later. >>>> >>>> We have standard committer and author fields for commits, and extra >>>> data captured by github during the PR process that is collated into all the >>>> contributors when release notes are generated. If we can think of ways to >>>> leverage that and write *less* or *no* code, that's even better. Could >>>> you come up with conventions for our commit log messages, including >>>> trailers? The commit could be force-pushed anytime before the PR is merged. >>>> >>> -- Edward E. Kang [email protected] 972-768-6940
