+1. One question: what should we put in the ()? Suppose I changed the TexeraWebApplication by adding a new endpoint, my title should can start with feat(backend), feat(core/texera) and many other possibilities. In this case, can you propose a set of rules that help developers decide what should be put in ().
Thanks, Jiadong Bai On Wed, Jul 2, 2025 at 1:44 PM Yicong Huang <[email protected]> wrote: > Hi all, > > Currently, our PR titles and commit messages are written primarily for > human readability. While that’s useful, adopting a more structured format > would allow us to automate downstream processes more easily — such as > generating changelogs, release notes, and filtering commits by type. > > To that end, I propose we adopt the Conventional Commits specification > < > https://urldefense.com/v3/__https://www.conventionalcommits.org/en/v1.0.0/__;!!CzAuKJ42GuquVTTmVmPViYEvSg!Mx0tGspXMOLMH-n25P_wrSF-bziiiii8QV-1CHHKgv7h87oP5CcLaqgUwN_3JRB_OMIg2WxQZRo_QnInA8Lcow$ > >. Specifically, this would > apply to: > > > 1. > > *Commit messages* > 2. > > *Pull request titles* (which become the squashed commit message in the > master branch) > > This format adds semantic meaning to commits using a simple prefix like > feat:, fix:, or docs: — for example: > > - feat(operator): add a new join operator > > - fix(ui): resolve layout issue > > - chore(ci): update GitHub Actions matrix > > > Unless there are objections, I’d like to move forward with adopting and > enforcing this convention going forward. > > > Best regards, > Yicong Huang >
