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. >> >
