This category of health checks focuses on the code you check into your GForge Next project, how it relates to task management, team and file sizes.
Commits Per Tracker Item
Definition: The number of separate commits associated to each Tracker Item in your project. Only commits created in the last 90 days are used, so the trends will change over time.
What it means: Having too many commits makes it harder to understand the associated Tracker Item’s history later on. It can also skew Sprint, Burndown, and Release metrics to look bigger or smaller than they really are.
How to fix? Although you can add or remove associations between a commit and a Tracker Item, it’s better to look forward than try to change history. When planning a Sprint or Release, consider the size of each Tracker Item, and break them down into smaller tasks that might affect fewer files, or involve fewer iterations for each TI.
Commits with Tracker Items
Definition: The percentage of commits in the last 90 days that are associated (or not) to a Tracker Item. Also checks for commits that are tied to more than on TI.
What it means: Pushing commits without an associated task is an easy way to mess up your code base over time. It’s also bad for team collaboration and Sprint and/or Release tracking.
How to fix? To fix existing commits, you can create Tracker Items, and associate them using the SCM Commits listing. Click a commit and use the “Tracker Item Associations” section at the bottom of the commit details view.
You can (and should) also fix the process for pushing commits to your project:
- Go to the Project Admin SCM tab, and choose “Require” for the “Associate Tracker Items” option.
- You might also check the “Restrict Tracker Item Associations” setting, depending on whether you want to allow associations between commits in this project and Tracker Items from other projects.
- Usually, this setting should be “Yes” to keep it to the current project.
Committers
Definition: The number of users with commits in the last 90 days, and the proportion of all commits made by each user.
What it means: For smaller projects (with only one or two contributors) this check won’t mean much. For full-sized Agile teams (4-5 contributors) or larger, traditional teams (10 or more contributors), this check can help you understand if work is balanced properly between team members.
How to fix? If you’re not using Tracker Items (and requiring that commits tie to them), then you should start right away. Having a specific task should be required in order to make code changes anyway, and an official task list lets the Product Owner, Scrum Master, or even the team itself to balance tasks among contributors by size, functional area and dependencies. Proper task balancing will lead to balanced commits from the team.
Files Per Commit
Definition: The number of files changed (or added, or removed) by each commit. Only commits created in the last 90 days are used, so the trends will change over time.
What it means: In general, commits should touch less than ten files. Large commits (many files and/or many lines of code) are harder to review, harder to understand later, and more likely to cause merge conflicts with other commits.
How to fix? This is another one where what’s done is done. Going forward, make sure that the team is doing proper analysis on task sizes during planning, and on the changes to be made when working each task. If a specific task requires changing many files, try to find a way to iterate on it, changing a few files in one commit, reviewing/merging that commit, then moving on to the next set of files.
Of course, sometimes you’ll just need to bite the bullet – a breaking change in a dependency/library, an urgent security fix, etc. But those hefty commits should be the exception and not the rule.
