Comments Categorization

Last updated 8 months ago

Was this helpful?

Comments Categorization

Explainer Video:

The "Comments Category" column in the Pull Requests tab is an AI-powered feature that automatically analyzes and categorizes comments into specific labels based on their content.

This feature helps you quickly understand the overall sentiment and focus of the comments within each pull request, making it easier to address issues and manage code reviews.

We categorize the Pull request in the below categories:

Type 1:

LGTM: PRs that are merged without significant issues or objections i.e. comments indicating approval, positive feedback on the implementation, or minor suggestions that are quickly addressed without major revisions.
- For example, "Great job! This looks perfect and works as expected."
Refactor: PRs that need significant changes to improve code quality or structure before they can be merged i.e. comments suggesting extensive changes, restructuring, or optimization of the code.
- For example, "The algorithm here can be optimized for better performance."
Buggy: PRs that introduce new bugs or issues into the codebase i.e. comments highlighting bugs, regressions, or issues that break existing functionality.
- For example, "This change breaks the login functionality."
Controversial: PRs that generate significant debate or disagreement among reviewers i.e. comments that show differing opinions or disputes on the implementation, approach, or necessity of the changes.
- For example, "I don't think this approach is the best solution."

Type 2:

Code Quality: Comments focused on the overall design, architecture, and cleanliness of the code i.e. feedback related to code organization, modularity, adherence to design patterns, and overall structural improvements.
- For example, "This module should be broken down into smaller, more manageable components."
Readability: Comments aimed at improving the readability of the code and the adequacy of its documentation i.e. feedback about code clarity, naming conventions, comments within the code, and the presence and quality of documentation.
- For example, "Variable names should be more descriptive."
Testing: Comments that address the sufficiency and quality of tests and error handling mechanisms. Suggestions or concerns regarding unit tests, integration tests, error handling, edge cases, and the robustness of the code against failures.
- For example, "Error handling is not sufficient here; consider adding more checks."
Compliance: Comments that ensure the code adheres to industry standards, coding guidelines, and best practices i.e. feedback on adherence to coding standards, security practices, regulatory compliance, and the use of recommended libraries or frameworks.
- For example, "This code doesn't comply with our security guidelines."
Maintainability: Comments that focus on the long-term maintenance and scalability of the code. Suggestions for making the code easier to maintain, extending its functionality, or improving performance to handle larger scale or more complex operations.
- For example, "This code will be hard to maintain; consider refactoring."

Type 3: Special Cases for Categorization:

When a comment consists of a single word, it is categorized as a "One Word Comment".
If a pull request has no comments, it is categorized as "No Comment".
When a pull request cannot be categorized based on its comments due to various reasons, it is categorised as "No Value".

Wherever applicable, each PR will be categorized into either one or two of the above types. For example -

"Looks good to me. Well done on keeping the code clean and efficient!"
- Categories: LGTM, Code Quality
“Consider refactoring this function to reduce its complexity and improve readability.”
- Categories: Refactor, Readability
“There's a bug in the validation logic. Please fix it before merging”
- Categories: Buggy
"Looks good to me. Well done on keeping the code clean and efficient!" "Can you add more comments to this section for better understanding?"
- Categories: LGTM, Readability
"There's a bug in the validation logic. Please fix it before merging." "Make sure to add unit tests to cover this scenario."
- Categories: Buggy, Testing

Please note: For this feature to work, we process the metadata through AI.

PreviousPull Request NextReview Cycles

Last updated 8 months ago

Was this helpful?

Explainer Video:

The "Comments Category" column in the Pull Requests tab is an AI-powered feature that automatically analyzes and categorizes comments into specific labels based on their content.

This feature helps you quickly understand the overall sentiment and focus of the comments within each pull request, making it easier to address issues and manage code reviews.

We categorize the Pull request in the below categories:

Type 1:

LGTM: PRs that are merged without significant issues or objections i.e. comments indicating approval, positive feedback on the implementation, or minor suggestions that are quickly addressed without major revisions.
- For example, "Great job! This looks perfect and works as expected."
Refactor: PRs that need significant changes to improve code quality or structure before they can be merged i.e. comments suggesting extensive changes, restructuring, or optimization of the code.
- For example, "The algorithm here can be optimized for better performance."
Buggy: PRs that introduce new bugs or issues into the codebase i.e. comments highlighting bugs, regressions, or issues that break existing functionality.
- For example, "This change breaks the login functionality."
Controversial: PRs that generate significant debate or disagreement among reviewers i.e. comments that show differing opinions or disputes on the implementation, approach, or necessity of the changes.
- For example, "I don't think this approach is the best solution."

Type 2:

Code Quality: Comments focused on the overall design, architecture, and cleanliness of the code i.e. feedback related to code organization, modularity, adherence to design patterns, and overall structural improvements.
- For example, "This module should be broken down into smaller, more manageable components."
Readability: Comments aimed at improving the readability of the code and the adequacy of its documentation i.e. feedback about code clarity, naming conventions, comments within the code, and the presence and quality of documentation.
- For example, "Variable names should be more descriptive."
Testing: Comments that address the sufficiency and quality of tests and error handling mechanisms. Suggestions or concerns regarding unit tests, integration tests, error handling, edge cases, and the robustness of the code against failures.
- For example, "Error handling is not sufficient here; consider adding more checks."
Compliance: Comments that ensure the code adheres to industry standards, coding guidelines, and best practices i.e. feedback on adherence to coding standards, security practices, regulatory compliance, and the use of recommended libraries or frameworks.
- For example, "This code doesn't comply with our security guidelines."
Maintainability: Comments that focus on the long-term maintenance and scalability of the code. Suggestions for making the code easier to maintain, extending its functionality, or improving performance to handle larger scale or more complex operations.
- For example, "This code will be hard to maintain; consider refactoring."

Type 3: Special Cases for Categorization:

When a comment consists of a single word, it is categorized as a "One Word Comment".
If a pull request has no comments, it is categorized as "No Comment".
When a pull request cannot be categorized based on its comments due to various reasons, it is categorised as "No Value".

Wherever applicable, each PR will be categorized into either one or two of the above types. For example -

"Looks good to me. Well done on keeping the code clean and efficient!"
- Categories: LGTM, Code Quality
“Consider refactoring this function to reduce its complexity and improve readability.”
- Categories: Refactor, Readability
“There's a bug in the validation logic. Please fix it before merging”
- Categories: Buggy
"Looks good to me. Well done on keeping the code clean and efficient!" "Can you add more comments to this section for better understanding?"
- Categories: LGTM, Readability
"There's a bug in the validation logic. Please fix it before merging." "Make sure to add unit tests to cover this scenario."
- Categories: Buggy, Testing

Please note: For this feature to work, we process the metadata through AI.

If you cannot see this column in the Pull Request screen, please contact our support team at