Soneso Stellar SDK Stats

Definitions

• Profiles export this dashboard's raw signals, samples, coverage, freshness, and evidence following the maintenance-profile proposal; uncollected signals and percentiles are null with reasons. There is no comparison pool or combined score.
• All times are UTC. Each source shows its own last successful collection time; a green build never implies every source is fresh.
• Release cadence (shown on the maintenance cards as median release gap): median gap in days between stable (non-prerelease) GitHub releases, over gaps whose later release falls in the trailing 365 days. GitHub publication is the shipping proxy; registry artifacts may lag briefly.
• Commit activity: GitHub's per-day commit counts for the default branch, shown for the trailing 365 days.
• Open issues and PRs: complete scan of all open items at the stated observation time (no window). Zero shows a real zero; median age at zero is not applicable.
• Community cohort: issues and PRs created in the trailing 365 days, excluding self-filed (owner/member), bot-authored, and removed items. Counts are shown as opened and closed, never percentages. Median time to close covers the closed items of this cohort, from creation to closure.
• Maintainer PRs count owner/member-authored pull requests created in the same trailing 365 days, as workload context; bot-authored PRs (dependabot and similar) belong to neither cohort and are not shown.
• Responsiveness (definition v3): community issues and PRs created in the trailing 90 UTC calendar days, including today (89-day offset), with the same exclusions as the community cohort. A of N counts eligible items whose first qualifying response arrived within 48 elapsed hours, including exactly 48h. No percentage or combined score is shown. An empty denominator reads no eligible items; incomplete or pre-v3 data reads n/a.
• Eligibility requires a full 48 hours of observation, even when already answered. The clock starts at creation; for a PR created as a draft, it starts at its first ready-for-review event. Later draft conversions do not restart the clock. A response before readiness has zero elapsed response time. If draft readiness cannot be established, creation is retained as a fallback timestamp but the unknown clock is counted and excluded from N.
• Qualifying issue comments, submitted PR reviews, and PR review comments must have OWNER, MEMBER, or COLLABORATOR association, come from a login not ending [bot], and not be by the item author. Pending reviews do not count. A review comment counts from when it became visible: the later of its creation and its parent review submission; comments in unsubmitted reviews do not count. For PRs, a human non-author merge or close also counts. For issues, only a close linked to a commit or merged PR counts; a manual click-close never counts. Full pagination is required. A cross-reference alone does not prove closure: GitHub must identify the closing commit or merged PR.
• If an unresolved actor could change the first-response result, attribution is unknown and the item is excluded from N and the median. Unknown attribution and clock counts cover the full cohort and may overlap pending items and each other. Unanswered eligible items stay in N. Median first response uses answered eligible items in the same 90-day cohort, including slow responses; the separate close medians retain their 365-day creation cohort. PR disposition covers all community PRs in the 90-day cohort, including pending and unknown items.
• Response evidence expands below each SDK card. Closed, answered v3 records are cached while their source update time is unchanged; open, unanswered, unknown, changed, or legacy records are collected again. A response-fetch failure makes the response section incomplete and preserves its last successful timestamp; the closure and backlog metrics remain independently covered.
• Differences from the maintenance-signals proposal: this dashboard uses 48h instead of the proposed seven days, counts qualifying PR discussion and review comments as well as submitted reviews, and explicitly handles draft readiness as above. It uses counts, without percentile ranks or a comparison pool. Author exclusions remain OWNER/MEMBER and bots; there is no declared-maintainer login override. Coverage is complete/incomplete, missing data is n/a, and retained values older than 48h are marked STALE in the freshness table; host-repository and external-tracker exemptions are not configured for these four repositories.
• Protocol Delivery: maintainer-verified entries only. A supporting release is the first stable GitHub release whose notes explicitly announce the usable protocol API, not preliminary XDR adoption. Shipping uses the GitHub publication date as a proxy, not registry publication or testnet activation. Lag is publication minus mainnet activation in UTC calendar days; early, same-day, and later delivery are descriptive, with no judgment coloring. Each row links the release, CAP, and activation evidence.
• Downloads: pub.dev values are pub.dev-reported rolling 7-day totals as observed at collection (not calendar weeks); Packagist values are calendar-month sums of Packagist's daily download counts (current month partial); KMP values are Maven Central artifact downloads reported via Scarf over the stated windows (about one week of ingest lag); iOS shows git clone traffic, the retrieval path SPM and CocoaPods installs use, with the same CI/bot noise as any registry download count.
• Production users and community feedback are curated examples with public evidence links, verified on the stated date; never a census. GitHub star counts in the users table are maintainer-set snapshots for open-source user projects, linked to the project repository and dated in the curated file; closed-source or off-GitHub projects show a dash. Community feedback links to the public PG Award proposal threads where users and community members posted their comments; the counts cover maintainer-verified comments. The dependents number is GitHub's dependents-graph count; it is shown only where the graph can attribute dependents to the repository (pub.dev and Composer manifests). SPM manifests are not parsed by the graph, and Maven/Gradle coordinates are not mapped back to source repositories, so iOS and KMP read not tracked instead of a false zero.