Document what a refs_changed event actually means - #68
Merged
Merged
Conversation
Reading `repo:refs_changed` as developer activity is wrong: of 16 295 master-ref events in production data, ~15 000 were release tooling and the 1 210 human-authored ones were merge commits already counted as pr:merged. `change_type` inherits the problem - a master push has no branch prefix, so change mix over all events reads 83 percent "other" and says nothing. README gets a "Reading the event tables" section with the numbers; AGENTS.md gets the rule, since that is what steers a reader before they query.
Prose to terse rules: 11.5k to 8.2k chars, every rule kept. Dropped what the code already states - router signatures, sample-file contents, what riptide.json declares field by field - and kept the invariants, the measured facts behind them, and the naming and layering constraints. Merged the automation bullets into one that states the detection order, and added the empty-string convention for optional fields that came out of the last review.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Reading
repo:refs_changedas developer activity is wrong, and the numbers are stark. Of 16 295 master-ref events in 3.5 months of production data:[maven-release-plugin] prepare for next development iteration,[gradle-release] …, a component-version job (6 468 alone), and Renovate landing updatesPull request #NNN: …) already counted on the PR side aspr:mergedNobody is pushing to master; the events are bookkeeping. Any per-author or per-repo activity view built on them is ~93 % release automation.
change_typeinherits the problem: it is parsed frombranch_name, so a push tomasterhas no prefix to classify. Computed over all events it reads 83 %other, which was easy to misread as "the team doesn't use branch prefixes" when in factfeature/andbugfix/are used consistently on PRs.README gets a "Reading the event tables" section with the mechanism and the numbers; AGENTS.md gets the rule, since that is what an agent reads before querying. The change-mix row now says to restrict the distribution to PR events.
Docs only, no code. Tests: 235 pass.