Configure Developers and Teams

Your knowledge maps are based on colors to give you an accessible high-level overview. The system will automatically assign a distinct color to each top-contributor in your codebase on the first analysis. But you still need to assign a color to the other developers if you want to identify them in the visualizations. Similarly, you can define teams of developers and assign each team a color as well.

Sample on colored knowledge maps

Fig. 59 Sample on colored knowledge maps.

Click the Team Configuration link in your repository to proceed to the configuration:

Configure team and developer information

Fig. 60 Configure team and developer information.

Run an initial Analysis before you configure Developers

Empear Enterprise will mine a list of all contributing developers. Note that this list is mined and updated during each analysis. That means you need to run one initial analysis before the tool gives you the option to configure developer properties!

Define your Development Teams

For each team in your organization, specify the following properties:

  • Team name: This will be used to identify the team. Later, when you configure developers, you’ll assign them to the team names you chose here.
  • Team Color: The team color is used in the visualization of knowledge distribution on team level (see the knowledge guide for some examples).

Tip: Some organizations just use one development team. In that case, introduce virtual teams that depend upon the responsibilities of the different developers. For example, you might want to define a Feature team, a Maintenance team and an Infrastructure team. Using this strategy, you’d be able to identify code at risk for incompatible parallel changes since different forces lead to the changes.

Even open-source Software has Teams

The team definition is straightforward if you analyze a codebase that’s owned by a traditional organization; Just use the information from your organizational chart. However, we find it interesting to apply teams to open-source codebases as well.

So if you happen to analyze an open-source project, consider introducing the following teams to get additional social information:

  • Define a teams for the organization that owns the code. For example, if you analyze the Clojure codebase, you’d define Cognitect as one team. If you analyze one of Microsoft’s open-source codebases, you’d use Microsoft as one team.
  • Define a team for third party developers that contribute to the codebase
  • Consider defining a team of the core maintainers too.

Configure Developer Properties

The developer properties are a bit more tricky than the team configuration, so please let us walk you through them one by one:

Clone developer information

Fig. 61 Clone developer information.

Empear Enterprise will automatically update the list of contributing developers; If a new developer starts to contribute code, they’ll be present in the list and the tool lets you configure their properties.

Here are the properties you need to specify:

  1. Color: The color is used on the knowledge maps to uniquely identify a developer. Try to assign the top contributors as distinct colors as possible.
  2. Active/Ex-Developer: By default, all developers are considered active. If some of them leaves your project, mark them as Ex-Developers through the drop down menu and Empear Enterprise will include them in the Knowledge Loss Analysis.
  3. Team: The third column lets you assign the developer to a team. That will include them in the Team Knowledge Distribution Analysis.
  4. Exclude author from analysis: If you check this option, the author will be excluded from all social analyses (although their contributions will still be included in the technical analyses like Hotspots and Code Churn). This is an option you use in case you have roles like System Integrators that only merge code, but never actually make their own contributions.

Once you’ve defined all developer properties you just need to run a new analysis and you’ll get a smorgasbord of interesting social analysis results.

Copy Developer and Team definitions

There are some cases where it makes sense to copy all developer and team configurations to a new repository configuration:

  • You run multiple analyses on the the same repository, for example to analyze different development periods.
  • You analyze multiple repositories that are maintained by the same people

In any of those cases, define your developers and teams for one repository and use the Copy Configuration operation to clone the information:

Clone developer information

Fig. 62 Cloning developer information from an existing repository.

Import a definition of Development Teams

It may well be impractical to configure each team and developer via the UI, particular for large organizations. That’s why Empear supports import of the organizational chart.

You find the import functionality in the Team configuration:

Import developer information

Fig. 63 Importing developer information by uploading a CSV file.

The input file specifies your organization. The file format has to be a CSV with two columns: author and team.