BTA Docs / Analysis reference

What each view tells you

BTA examines the language, timing, status, and activity recorded around repository work. This reference explains the inputs and calculations behind those views, the questions each can help investigate, and the conclusions it cannot establish.

Check the records behind a pattern.

A pattern helps you find where to investigate. Read the examples and check them with the people who know the system before drawing a conclusion.

Source fields

The standard collector uses the GitHub fields listed below. It collects comment counts, not full discussion threads, inline review text, or changed files. The published analyses also draw on additional sources described in their source notes. Available records depend on repository permissions and the selected scope.

Repository fields

Field	Meaning	Source
`num_pull_requests`	Total pull requests returned for the selected repository and scope.	GitHub API
`num_contributors`	Distinct contributors represented in the repository record.	GitHub API
`num_stargazers`	Current number of accounts that starred the repository.	GitHub API

Issue and pull-request fields

Field	Meaning
`id`, `number`	GitHub identifiers used to trace a result back to its source item.
`title`, `body`	The item title and description. These fields support search, word frequency, and topic analysis.
`state`	Whether the item is open or closed when the data is collected.
`user`	The GitHub account that created the issue or pull request; not necessarily its owner or resolver.
`comments`	The number of comments recorded for the item.
`labels`	The labels applied in GitHub. Label quality and conventions vary by repository.
`created_at`, `updated_at`, `closed_at`	Timestamps used to describe volume, activity, age, and closure timing.
`time_to_close`	Elapsed time from creation to closure for a closed item. Open items do not have a completed close time.
`html_url`	The source link used to return a reader to the item in GitHub.

Core metrics

Core metrics are direct counts or repeatable calculations from the repository record. They describe what is present in the data. They do not explain why it happened.

Item count

Direct

The number of issues or pull requests in the selected repository, date range, and query scope.

Output: Whole number
Inputs: Items returned by the GitHub API

What it can tell youHow much recorded work exists in the selected scope.

What it cannot tell youEffort, complexity, quality, or whether every unit of work was recorded in GitHub.

Open and closed distribution

Calculated

The count and proportion of items in each GitHub state at the time of collection.

Formula: Items in state / all items in scope
Output: Count and percentage

What it can tell youThe visible balance between completed and still-open work.

What it cannot tell youWhether open work is blocked, abandoned, intentionally long-running, or still valuable.

Time to close

Calculated

Elapsed time between created_at and closed_at for closed items. BTA reports mean, median, minimum, and maximum values.

Formula: closed_at - created_at
Unit: Days

What it can tell youWhether items tend to close quickly, slowly, or in separate timing groups. If many close quickly while others remain open for a long time, that pattern is worth examining.

What it cannot tell youWhy work took that long, whether speed was desirable, or how much active work occurred between the timestamps.

Resolution-time distribution

Calculated

Closed items grouped into elapsed-time ranges so the shape of closure timing is visible instead of being reduced to one average.

Inputs: Closed items with valid timestamps
Output: Count by time range

What it can tell youWhether work closes in one consistent range or is split between very short and very long durations.

What it cannot tell youWhether the ranges represent different work types, priorities, dependencies, or process problems.

Comment activity

Calculated

Total, mean, median, and maximum comment counts for items in scope.

Inputs: comments for each item
Output: Counts and summary statistics

What it can tell youWhere discussion is concentrated and which items may deserve closer review.

What it cannot tell youDiscussion quality, alignment, difficulty, or communication that occurred outside GitHub.

Activity over time

Calculated

Items grouped by creation date, cumulative item counts, current state grouped by creation date, and creation activity by day and hour. This is not a history of state transitions.

Inputs: Creation timestamps and current item state
Output: Time series and heatmap counts

What it can tell youWhen recorded activity increased, decreased, or clustered.

What it cannot tell youCapacity, productivity, urgency, or the cause of a change in activity.

Contributor distribution

Calculated

Counts of issues and pull requests created by each author. The standard summary returns the ten most frequent authors; repository contributor count is a separate field.

Formula: Items created by an author; any percentage must name its denominator
Output: Count and percentage

What it can tell youWhich accounts created many of the collected records. This does not show who reviewed or resolved them.

What it cannot tell youIndividual performance, expertise, ownership quality, invisible work, or whether concentration is appropriate.

Relationships and flow

Calculated

The collaboration matrix counts shared labels between authors. Label flow groups current labels by open or closed state. Other views compare duration with comment count or show closure dates.

Inputs: Normalized work-record data
Output: Matrix, flow, timeline, or scatter data

What it can tell youWhere authors share labels and where timing or comment counts warrant a closer look. These views do not reconstruct handoffs or label-change history.

What it cannot tell youOrganizational reporting lines, collaboration quality, or causation.

Text and topic analysis

BTA can organize the language in titles and descriptions to make a large record easier to inspect. These outputs depend on the text available in GitHub and the selected method.

Word frequency

Counts recurring terms after text preparation. It shows which words appear often, not why they appear or whether they are important.

Topic clusters

Groups items that use similar language. Cluster labels summarize shared terms and should be checked against representative source items.

Enhanced labels

When enabled, a configured model can propose clearer names for topic clusters. The label is model-assisted; the underlying items and terms remain the evidence.

Questions about the record

BTA can use retrieval for evidence questions or structured queries for counts and comparisons. Answers should retain their query or source route.

Experimental interpretations

These optional views use rules and assumptions to suggest where to investigate. Their names do not establish that they measure the condition they describe.

Use these to direct investigation.

Keep the formula, thresholds, and assumptions visible. Validate the result with source items and team context before using it in a decision.

Closure timing split

Compares closed items that took seven days or less with closed items that took more than ninety days. It highlights a possible split in how work moves, but does not identify the cause.

Language pattern

Compares selected maintenance-oriented and innovation-oriented terms in item titles. Results depend on the chosen vocabulary and how consistently titles describe the work.

Knowledge concentration

The dashboard calculates the top two authors’ share within the ten most frequent item authors returned by the summary. This describes authorship in that subset, not who resolved the work or holds the relevant knowledge.

Structural markers

Maps recurring topics or keywords to predefined planning categories. The rule-based mapping is a prompt to inspect the related work.

Effective capacity

Combines repository indicators using explicit weights and caps. This is an exploratory composite, not actual team capacity or a staffing recommendation.

Innovation tax

Compares selected maintenance and innovation language. The ratio describes that vocabulary model only; it does not measure innovation output.

Coordination-cost estimate

Applies stated team-size, compensation, and benchmark assumptions to model a possible cost. It is a scenario calculation, not an observed financial result.

Data handling and provenance

BTA runs in the customer environment. It retrieves the permitted GitHub record, normalizes it, stores a local cache, computes analysis outputs, and presents the results.

1
Retrieve
Read the selected record from GitHub or GitHub Enterprise with customer-provided access.
2
Normalize
Convert source responses into consistent repository and work-item fields.
3
Cache
Store retrieved data and generated vectors in local SQLite storage for reuse.
4
Calculate
Generate metrics, distributions, topic outputs, and source-linked views.
5
Present
Organize the evidence so people can examine it and decide what to do.

What to record with an analysis

Repository and query scope
Data-through date and collection time
Cache or API source and refresh status
Calculation version, thresholds, and configuration
Missing fields, permission limits, and known gaps

Model boundary

Core repository collection and metric calculation do not require a model to decide what the record contains. Optional features can use a model selected and configured by the customer.

Inside the customer environment

GitHub retrieval, normalization, local SQLite cache, metric calculations, and report serving.

Optional configured provider

Selected prompts or evidence may be sent for enhanced topic labels, synthesis, embeddings, or question answering.

The customer controls the provider, model, credentials, feature use, and the policies that apply to transmitted data.

How to read the results

Start with the scope

A metric describes only the repositories, dates, item types, and fields included in the analysis.

Return to the source

Use counts and patterns to locate representative items, then inspect the work behind them.

Ask what is missing

GitHub does not contain every decision, dependency, conversation, or contribution.

Add human context

Teams explain history, intent, constraints, and exceptions that repository data cannot establish.

Keep inference visible

Separate direct fields, calculated metrics, heuristic interpretations, and model-assisted language.

See how these definitions support a real analysis.

Read the Next.js full analysis