Context
Third of four one-source tickets, and the deliberate per-version counterpart to the two library achievements
before it.
Library Authoring counts libraries authored. Library Maintenance counts libraries maintained, deduplicating
across versions on purpose. This one counts releases authored, one grant per version, with thresholds
scaled accordingly (10 / 27 / 73 / 197 / 533).
Read together, the three touch almost the same data and mean three different things, which is why they are
three tickets. The property that distinguishes this one is simply that two authored versions of the same
library must produce two grants - the exact case the maintenance iterator collapses to one.
As in the sibling tickets, the engine from the earlier ticket offers two ways to run a source: a backfill,
which grants what is missing and never removes anything, and a reconcile, which also removes grants the
source no longer supports.
Scope
- A source iterator - the function the ingestion engine walks for one achievement - yielding
(member, library version) for every per-version authorship, with authors prefetched.
- Register it against its achievement, so it becomes selectable in the commands and the admin.
- An end-to-end test asserting the grain directly: two authored versions of one library produce two grants.
Out of scope
- Library-level authorship and maintainership. Separate tickets.
- Fixing the upstream authorship data.
- Scheduled runs.
Acceptance criteria
Risks & considerations
This is the highest-volume of the three library sources. Every release of every library yields a pair, so
the grant table grows with the release history rather than the library list. The iterator must read in
chunks rather than loading the lot, and the engine inserts grants in batches, which has to hold up at this
size.
Same upstream data caveat as Library Authoring: libraries.json carries a placeholder 'various ' author on
78 LibraryVersion rows. A reconcile moves the grants once that is fixed upstream.
The thresholds here are the largest of any badge, so they are the most likely to need retuning once real
volume is visible. That is a threshold decision, not a change to this iterator.
Context
Third of four one-source tickets, and the deliberate per-version counterpart to the two library achievements
before it.
Library Authoring counts libraries authored. Library Maintenance counts libraries maintained, deduplicating
across versions on purpose. This one counts releases authored, one grant per version, with thresholds
scaled accordingly (10 / 27 / 73 / 197 / 533).
Read together, the three touch almost the same data and mean three different things, which is why they are
three tickets. The property that distinguishes this one is simply that two authored versions of the same
library must produce two grants - the exact case the maintenance iterator collapses to one.
As in the sibling tickets, the engine from the earlier ticket offers two ways to run a source: a backfill,
which grants what is missing and never removes anything, and a reconcile, which also removes grants the
source no longer supports.
Scope
(member, library version)for every per-version authorship, with authors prefetched.Out of scope
Acceptance criteria
Risks & considerations
This is the highest-volume of the three library sources. Every release of every library yields a pair, so
the grant table grows with the release history rather than the library list. The iterator must read in
chunks rather than loading the lot, and the engine inserts grants in batches, which has to hold up at this
size.
Same upstream data caveat as Library Authoring:
libraries.jsoncarries a placeholder'various 'author on78
LibraryVersionrows. A reconcile moves the grants once that is fixed upstream.The thresholds here are the largest of any badge, so they are the most likely to need retuning once real
volume is visible. That is a threshold decision, not a change to this iterator.