Pull Request's Tags

Rocket.Chat encourages contributions from developers worldwide. One of the primary ways to contribute is through pull requests (PRs). PRs are a critical part of maintaining and improving the software, and they can range from bug fixes to the addition of new features. However, it's essential to follow specific guidelines when submitting a PR to ensure clarity and ease of understanding for the reviewers. This guide provides a succinct overview of the best practices for creating PRs for Rocket.Chat.

When contributing to Rocket.Chat, it's crucial to choose the right PR tag to describe your work accurately. These tags can include:

feat|fix|ci|chore|docs|test|refactor|i18n|regression|revert

Here's a brief explanation of each:

PR Tag Used when Method Bad example Good example

PR Tag	Used when	Method	Bad example	Good example
`feat:`	Use this tag when adding a new feature that is significant to the end-user.	The title should describe what's being added, not how it was added. Should not repeat `Add ...` , `New ...` or `Feature...`	`feat: Add the ability to set tags in the Omnichannel room closing dialog feat: Adds the ability for Rocket.Chat Apps to create discussions feat: Add MMS support to Voxtelesys feat: Add Color variable to the left sidebar`	`feat: Ability to set tags in the Omnichannel room closing dialog feat: Ability for Rocket.Chat Apps to create discussions feat: MMS support to Voxtelesys feat: Color variable to the left sidebar`
`fix:`	This tag is for fixing something not working or behaving incorrectly from the end-user perspective.	The title should describe what's being fixed, not how it was fixed.	`fix: Add Content-Type for public files with JWT`	`fix: Missing Content-Type header for public files with JWT`
`chore:`	Use this for small tasks such as changing a function name or something very quick that doesn't fit in another category.	The title should describe what's being changed, not how it was changed.	chore: Renaming `getNewMessage` function and replacing it in all files that use this function	chore: Rename `getNewMessage` function
`docs:`	This tag is for documentation such as README.md files, and other markdown and instruction files that bring value to the community.	The title should describe what's being changed, not how it was changed.		`docs: Update Pull Request Template`
`refactor:`	Use this for a code refactor that doesn't change behavior (it doesn't add anything and doesn't fix anything) such as converting a JavaScript file to TypeScript.			`refactor: RoomInfo to typescript`
`ci:`	This tag is for changes that update or add a CI configuration.			`ci: PR title check to use conventional commits`
`test:`	This tag is for adding tests.			`test: RoomInfo e2e tests`
`i18n:`	Use this for updating or adding any translations.			`i18n: Homepage translations to pt-BR`
`regression:`	This tag is for changes made during any release candidate cycle to add something missing fix something broken during the last development cycle and not published to a final release yet.			regression: Fix not being able to mark room as read regression: Add missing field to `users` endpoint

feat:

Use this tag when adding a new feature that is significant to the end-user.

The title should describe what's being added, not how it was added.

Should not repeat Add ... , New ... or Feature...

feat: Add the ability to set tags in the Omnichannel room closing dialog
feat: Adds the ability for Rocket.Chat Apps to create discussions
feat: Add MMS support to Voxtelesys
feat: Add Color variable to the left sidebar

feat: Ability to set tags in the Omnichannel room closing dialog
feat: Ability for Rocket.Chat Apps to create discussions
feat: MMS support to Voxtelesys
feat: Color variable to the left sidebar

fix:

This tag is for fixing something not working or behaving incorrectly from the end-user perspective.

The title should describe what's being fixed, not how it was fixed.

fix: Add Content-Type for public files with JWT

fix: Missing Content-Type header for public files with JWT

chore:

Use this for small tasks such as changing a function name or something very quick that doesn't fit in another category.

The title should describe what's being changed, not how it was changed.

chore: Renaming `getNewMessage` function and replacing it in all files that use this function

chore: Rename `getNewMessage` function

docs:

This tag is for documentation such as README.md files, and other markdown and instruction files that bring value to the community.

The title should describe what's being changed, not how it was changed.

docs: Update Pull Request Template

refactor:

Use this for a code refactor that doesn't change behavior (it doesn't add anything and doesn't fix anything) such as converting a JavaScript file to TypeScript.

refactor: RoomInfo to typescript

ci:

This tag is for changes that update or add a CI configuration.

ci: PR title check to use conventional commits

test:

This tag is for adding tests.

test: RoomInfo e2e tests

i18n:

Use this for updating or adding any translations.

i18n: Homepage translations to pt-BR

regression:

This tag is for changes made during any release candidate cycle to add something missing
fix something broken during the last development cycle and not published to a final release yet.

regression: Fix not being able to mark room as read 
regression: Add missing field to `users` endpoint

Contributing to Rocket.Chat through pull requests is a valuable way to improve the platform and engage with the open-source community. By following these guidelines for PR tags, contributors can ensure their work is understood and appreciated by the Rocket.Chat team and the broader community. Remember, the key is to describe what's being changed, fixed, or added, not how it was done. Happy contributing!

Last updated 9 months ago