The goal of this interactive map is to show engineer's experience in the codebase area and knowledge distribution between team members.
Map file structure reflects the development branch (master in case of trunk based development). In example, if you have deleted a folder in your feature branch, map structure will be updated once your branch is merged into development branch.
Metrics are calculated based on commits made to any branches currently detected by Codigy, except branches that are ignored (in example release branches).
It's exactly like having backups. If the knowledge is owned by a single engineer and no one can step in - it's risky.
Maintaining high levels of ownership and low levels of lost-knowledge with rotations and knowledge sharing practices.
If your team is working around the clock but the lost-knowledge keeps creeping in, it's probably because the product has outgrown your current team size.
An accurate map of experts can be used for peer-to-peer consultations or selecting speakers for team-wide events.
Lost knowledge - files that haven't been modified by anyone for a long time. It would take a similar amount of time for an original author to recover the working knowledge of these files as for a new engineer.
Lost knowledge is risky for a product as your team would either move slower in these files or have a significantly higher risk of defects.
Owner - an estimated best expert in the area. Can provide accurate estimates, make risk free changes, and help in knowledge sharing activities
Significant contributor - has similar qualities to that of the owner. An important role that significantly boosts the resilience of the product.
Contributor - holds a basic knowledge of the file, doesn't introduce any risks or benefits unless the file is overcrowded.
Micro contributor - an engineer with no prior knowledge of the file who introduces small changes. Commits made by micro contributors pose a higher risk of defects. Prevent micro contribution or upgrade such contributors to a higher knowledge tier.
Files with no defined owner - have multiple contributors without sufficient knowledge to be classified as significant contributors or owners. Such files have a higher risk of defects.
Bus factor - estimates how many engineers could leave the current team before the product will come to a full stop.
Active set - highlights the files that were recently changed. Allows you to focus your attention on the issues that are relevant for your team right now. The period that is considered recent, can be configured in account settings.
For higher accuracy, we recommend excluding external libraries, autogenerated and binary files.
Excluded files will not be visible on the map and changes made in these files will not be reflected in Confidence map metrics.
Files that are already ignored by gitignore, will be excluded from you Codigy analytics. To exclude more files specifically from your Codigy analytics, please create a file following these guidelines:
A codigyignore file specifies intentionally untracked files that Codigy should ignore.
Each line in a codigyignore file specifies a pattern. When deciding whether to ignore a path, Codigy checks codigyignore patterns from multiple sources, with the following order of precedence, from highest to lowest (within one level of precedence, the last matching pattern decides the outcome):
Patterns read from a .codigyignore file in the same directory as the path, or in any parent directory (up to the top-level of the working tree), with patterns in the higher level files being overridden by those in lower level files down to the directory containing the file. These patterns match relative to the location of the .codigyignore file.
A blank line matches no files, so it can serve as a separator for readability.
A line starting with # serves as a comment. Put a backslash ("\") in front of the first hash for patterns that begin with a hash.
Trailing spaces are ignored unless they are quoted with backslash ("\").
An optional prefix "!" which negates the pattern; any matching file excluded by a previous pattern will become included again. It is not possible to re-include a file if a parent directory of that file is excluded. Git doesn’t list excluded directories for performance reasons, so any patterns on contained files have no effect, no matter where they are defined. Put a backslash ("\") in front of the first "!" for patterns that begin with a literal "!", for example, "\!important!.txt".
The slash / is used as the directory separator. Separators may occur at the beginning, middle or end of the .codigyignore search pattern.
If there is a separator at the beginning or middle (or both) of the pattern, then the pattern is relative to the directory level of the particular .codigyignore file itself. Otherwise the pattern may also match at any level below the .codigyignore level.
If there is a separator at the end of the pattern then the pattern will only match directories, otherwise the pattern can match both files and directories.
For example, a pattern doc/frotz/ matches doc/frotz directory, but not a/doc/frotz directory; however frotz/ matches frotz and a/frotz that is a directory (all paths are relative from the .codigyignore file).
An asterisk "*" matches anything except a slash. The character "?" matches any one character except "/". The range notation, e.g. [a-zA-Z], can be used to match one of the characters in a range. See fnmatch(3) and the FNM_PATHNAME flag for a more detailed description.
Two consecutive asterisks ("**") in patterns matched against full pathname may have special meaning:
A leading "" followed by a slash means match in all directories. For example, "/foo" matches file or directory "foo" anywhere, the same as pattern "foo". "**/foo/bar" matches file or directory "bar" anywhere that is directly under directory "foo".
A trailing "/" matches everything inside. For example, "abc/" matches all files inside directory "abc", relative to the location of the .codigyignore file, with infinite depth.
A slash followed by two consecutive asterisks then a slash matches zero or more directories. For example, "a/**/b" matches "a/b", "a/x/b", "a/x/y/b" and so on.
Other consecutive asterisks are considered regular asterisks and will match according to the previous rules.
This page was last revised on September 29, 2021Return to main