The part in parentheses is called the scope. It is optional but helps reviewers understand which part of the code is affected. We do not need to enforce a strict list of scopes; they can follow developer convention.
For example, for adding a new API on the backend of result service, you could use feat(backend) for backend logic, feat(api) for a new API, or feat(result) for changes in the result service. The are all valid options. The more specific the scope, the easier it is to triage the PR, assign reviewers, and help future developers identify related changes. Best regards, Yicong Huang [email protected] On Jul 3, 2025 at 15:05 -0700, Jiadong Bai <[email protected]>, wrote: > +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://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fwww.conventionalcommits.org%2Fen%2Fv1.0.0%2F__%3B!!CzAuKJ42GuquVTTmVmPViYEvSg!Mx0tGspXMOLMH-n25P_wrSF-bziiiii8QV-1CHHKgv7h87oP5CcLaqgUwN_3JRB_OMIg2WxQZRo_QnInA8Lcow%24&data=05%7C02%7Cyiconghuang%40umass.edu%7Ca5fa24e831704658769f08ddba7db06f%7C7bd08b0b33954dc194bbd0b2e56a497f%7C0%7C0%7C638871771172867065%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=sfsuDNb44jAzmJIOe%2FuC9gf%2FBUJ%2FQ1yVY3IQtvH6Y%2FE%3D&reserved=0 > > > >. 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 > >
