You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Part of #6793. Depends on #6794 (the signal inventory this schema should be grounded in, not designed in the abstract).
Context
AMS needs a concrete data shape to represent what it's learned about a repo's contribution eligibility rules, before any extraction or discover integration can be built against it.
Eligibility label rules: which label(s) mark an issue as contributor-workable (loopover's gittensor:* is one instance, not the only possible shape — a generic repo might use help wanted/good first issue/something else entirely, or nothing).
Exclusion label rules: which label(s) mark an issue as maintainer-only / off-limits.
Assignee-exclusion rules: e.g. "not assigned to the repo owner."
Linked-issue / PR-body requirements: does a PR need to reference a specific issue with a closing keyword.
A confidence/completeness indicator: was this profile built from explicit, unambiguous signals, or inferred/partial — this matters for how conservatively discover should treat an uncertain profile.
Source provenance: which signal(s) each rule was derived from, for debuggability.
Decide the profile's storage/caching shape (a new local SQLite store mirroring existing miner stores like policy-doc-cache.sqlite3, keyed by repo, with a sensible TTL/refresh policy — labels and docs both change over time).
Deliverables
A documented schema (a markdown doc under packages/loopover-miner/docs/ alongside the existing miner-goal-spec.md precedent, plus any TypeScript/JSDoc type definitions needed for the implementation issues that follow).
No extraction logic or discover wiring in this issue — schema/design only.
Expected Outcome
The extraction-implementation and discover-integration sub-issues have a stable, precise target shape to build against.
Part of #6793. Depends on #6794 (the signal inventory this schema should be grounded in, not designed in the abstract).
Context
AMS needs a concrete data shape to represent what it's learned about a repo's contribution eligibility rules, before any extraction or
discoverintegration can be built against it.Requirements
ContributionProfileshape covering (informed by AMS contribution-profile: inventory real-world eligibility signals across a diverse repo sample #6794's actual findings, not assumed upfront):gittensor:*is one instance, not the only possible shape — a generic repo might usehelp wanted/good first issue/something else entirely, or nothing).discovershould treat an uncertain profile.policy-doc-cache.sqlite3, keyed by repo, with a sensible TTL/refresh policy — labels and docs both change over time).Deliverables
packages/loopover-miner/docs/alongside the existingminer-goal-spec.mdprecedent, plus any TypeScript/JSDoc type definitions needed for the implementation issues that follow).discoverwiring in this issue — schema/design only.Expected Outcome
The extraction-implementation and
discover-integration sub-issues have a stable, precise target shape to build against.