An "Active Contributor" in GitClear is any user who has made commits to your git repository in the past 30 days. Normally, customers want to process stats for all of their Active Contributors, but GitClear offers several options to configure which contributors end up being billed in the subscription.
linkSubscription Seats: A License to Developer Process Stats
For a contributor to have their stats processed & visible, they must possess a Subscription Seat. When you initially choose your GitClear subscription plan, you have the option to choose a specific number of Subscription Seats, and whether to automatically increase that number of seats as new contributors are encountered while processing git data.
Subscription Seats are not refundable, so you generally want to purchase only as many as you expect to have contributors during the renewal interval.
If you end up having unused seats, you can always assign those to past developers their stats are included for historical comparison. Past contributors data can be especially interesting in reports like the Cohort Analysis report.
Configure the number of Subscription Seats by visiting Settings -> Billing and Subscription -> Manage your subscription
linkOption: Automatically adjust seat count
When this option is selected, GitClear will increase or decrease your seat count if the number of Active Contributors is different than the number of seats you previously purchased. It is quickest to illustrate how "Automatically adjust seats" works by example, so we recommend checking out Subscription Seat processing examples. In a nutshell, even if "Automatically adjust" is checked, we will always seek to recapture licenses from non-active contributors before we increase your seat count. If developers have become inactive, or specifically had their license removed by an admin, then GitClear will detect an available Subscription Seat and will assign that to the newly activated developer.
If "Automatically adjust" is not checked, new developers will not be processed unless another developer stops contributing. If a developer leaves the team, the seat count will not reduce if the "Automatically adjust seat count" is not enabled.
linkAssigning Subscription Seats
By default, any contributor that has been exiled, or who has previously had their Subscription Seat removed by an admin, will not receive a Subscription Seat. That said, it's not uncommon for teams to only wish to process git stats for a subset of their active developers. This can be controlled by visiting Settings -> Contributors and clicking either the "Active Seat" logo, or the dropdown option from the right side of the row:
Upon clicking "Active Seat" or "Release Seat," a menu will open allowing you to reassign the Subscription Seat:
If you choose a specific developer, they will receive the Subscription Seat and will immediately have their stats begin processing. If no specific developer is chosen, then GitClear will automatically assign the open seat to the Active Contributor with the greatest amount of commits over the past month. A contributor who has their seat relinquished by an admin will not have a Subscription Seat automatically assigned to them, they will only begin processing stats again if the admin returns to the Contributors list and chooses "Acquire seat":
Choosing "Acquire seat" will utilize an existing Subscription Seat, if you have a one that is not utilized by an Active Contributor. If all of your current seats are allocated, then we will increase the count of seats to be renewed, such that this developer's stats will begin to show up on GitClear charts.
linkWhat gets processed without a Subscription Seat?
While a developer will not show in the Commit Activity Browser, Pull Request Stats, notifications, or Delivery Velocity graphs, there is still limited processing that takes place even when a developer doesn't possess a Subscription Seat. We will still show files that changed within the Directory Browser, and we will still keep track of the ancestry of code lines within the repo, so that we can present stats on the whether the team has been removing legacy code.
linkSubscription Seat processing examples
Since there are a lot of interesting and complex scenarios that can arise with real world teams, these examples help to illustrate how Subscription Seats are calculated under maximally complex circumstances.
linkExample Scenario 1: Small team with revolving contributors
During your trial, GitClear finds 3 contributors who have authored code in the last 30 days across all of your repos, and 10 contributors who made earlier contributions. The contributors who made earlier commits will factor in to some stats (like File Directory browser), but will not show up in Delivery Velocity Stats, Issue Stats, or Pull Request Stats. You purchase an annual subscription at the "Pro" level after your trial, which gives you three subscription seats for 12 months. After 2 months, one committer departs. Their stats will continue to be processed since you have 3 seats. Then the departed developer is replaced, and a new developer becomes active in your repos. At this point, GitClear will automatically remove the Subscription Seat from the departed developer (whose stats will no longer be present) and will begin processing stats for the new contributor. In this case, since there were never more than three Active Contributors at once, the "Automatically increase seats" option did not come into effect.
linkExample Scenario 2: A large team with intermittent contributors
When this company began their GitClear subscription, they purchased 400 annual licenses, with "Automatically increase seats" disabled. The company then hired 5 more developers, but did not want to incur the additional pro-rated cost of buying 5 more GitClear seats (if they did purchase 5 more seats, they would only be charged for the portion of the term between "current date" and "next subscription renewal"). To ensure that these new developers' stats were shown within GitClear, the CTO decided to relinquish his own Subscription Seat (since he rarely makes commits) and the Subscription Seats for 4 other Managers who only made commits a few times per month. These intermittent contributors will no longer show up in places where stats are processed, but the 5 new contributors will now have their data processed.
The relinquished seats will automatically be assigned to the new contributors within the following day, but it's also possible to begin processing the new developers' stats immediately upon relinquishing the Subscription Seat from the Contributors settings page:
Choosing which Contributor will inherit the Subscription Seat
linkExample Scenario 3: A team shifting to an Elite subscription with a shorter billing cycle
In this example, the company paid for 10 Subscription Seats at the Pro level during their previous renewal, 6 months ago. The new CEO has decided that they want to unlock the extra powers that come with an Elite subscription, but he wants to begin paying on a monthly cycle due to spread out costs.
The first option is to wait until the 6 months are finished, and let the Elite subscription kick in at that point. But if the company wishes to upgrade to Elite now, they can do that by paying the pro-rated cost of upgrading the existing seats until the end of the current renew interval. The first step is to visit the "Manage Subscription" page, choose "Elite" as the selected level, and choose "Monthly" as the billing interval. This will produce a link to "Review Changes" where the admin can decide whether they want to upgrade their subscription now or later:
Configuring a subscription to upgrade to Elite while downgrading to monthly billing
The following page describes this upgrade situation:
This price is calculated by taking the difference per month between Elite and Pro ($10), multiplied by 10 contributors over the 6 months that remain in the current billing cycle: 10 * 10 * 6 = $600 to upgrade all the contributors to Elite through the end of the current term. The subscription will begin to be billed monthly, at $260, thereafter.