Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

An assignee-only claim is invisible to newcomers and never expires

Open
  • Is something wrong?
#949 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
58/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
github-actions, javascript
Domain
ci-cd, documentation

Research direction

Start in .github/workflows/stale-claims.yml around the claim enumeration and existing idle/open-PR checks, then compare the claim protocol in CONTRIBUTING.md. Trace how an assigned issue without status:claimed is handled and preserve the workflow’s stated safety properties. Verify the acceptance criteria against #902 and confirm that both claim shapes are discoverable or expire consistently.

Written by the indexing model from the issue text.

Description

bug

Problem

A claim made by assigning without adding status:claimed is in the worst of both
states: invisible to every newcomer browsing for work, and immune to the 7-day expiry that
is supposed to release abandoned claims. The issue is parked indefinitely with nobody
tracking it.

The three halves that combine

1. The reaper only ever looks at labelled issues.
.github/workflows/stale-claims.yml:65-71 (on main):

const claimed = await github.paginate(github.rest.issues.listForRepo, {
  owner, repo, state: "open", labels: CLAIM_LABEL, per_page: 100,
});

CLAIM_LABEL is status:claimed (:56). An issue that is assigned but unlabelled is
never enumerated, so it is never considered for expiry, no matter how long it sits.

Notably the job already handles the mirror asymmetry — :144 has a dedicated message for
"the issue carried the label but no assignee" — so label-without-assignee was thought
through and assignee-without-label was not. The header comment at :6 defines a claim as
"status:claimed + an assignee", which is the definition the enumeration doesn't
implement.

2. Self-assignment is an endorsed path, and it is the one that forgets the label.
CONTRIBUTING.md's "Claiming an issue" section says "If you have write access and
assign yourself, add status:claimed too", and explains why: an assignee on its own "is
exactly the invisible claim described above — it is how #681 got built twice". Since #945,
the "Finding something to work on" section also routes write-access readers to self-assign.
Both rely on the human remembering the label; nothing enforces it.

3. Since #945, an unlabelled-but-assigned issue is also hidden from the newcomer list.
The good-first-issue link now carries no:assignee, so the issue drops out of the list new
contributors are told to start from.

Before #945 that issue at least stayed visible — someone would eventually see it and ask.
That visibility was itself a double-pickup hazard (which is why the filter was added, and
it was the right call), but it was also the only thing surfacing this state. Now nothing
does.

Failing scenario

  1. A maintainer with write access self-assigns #N and forgets status:claimed — the exact
    slip CONTRIBUTING.md warns about.
  2. #N is now excluded from the newcomer list by no:assignee.
  3. stale-claims.yml never enumerates #N, because it has no status:claimed label.
  4. The assignee goes quiet. Nothing expires, nothing comments, nobody browsing can see it.
  5. #N is parked permanently: not discoverable, not reapable, and not tracked as claimed by
    any tooling that reads the label.

This is live on the very issue #945 resolves. #902 is open, labelled
documentation, good first issue, assigned to @Samhit21, and carries no
status:claimed. It is absent from the filtered list and invisible to the reaper.

Why it matters

The claim protocol exists because two contributors independently built #681 while it was
assigned to a third — the reaper's own header says so. The docs promise, in the section
#945 links for details, that "Claims lapse… a scheduled job unassigns it, drops the label,
and comments to say so." For an assignee-only claim that promise is simply false, and the
reader has no way to tell which kind of claim they are looking at.

Proposed fix

Preferred: make the reaper sweep assignee-only claims too. A second enumeration of open
issues with an assignee and no CLAIM_LABEL, run through the same idle/open-PR checks.
Either expire it identically, or — gentler and probably better — just add the missing
status:claimed label so the existing path picks it up next run and the claim becomes
visible immediately.

Alternatives, not exclusive:

  • Backstop the slip on the way in: a workflow on issues: assigned that adds
    status:claimed automatically, which removes the human step the docs currently rely on.
  • Scope the docs' lapse promise to label-bearing claims, so it stops being false — the
    weakest option alone, since it documents the gap rather than closing it.

Acceptance criteria

  • An open issue that is assigned and carries no status:claimed is either reaped on the
    same idle rules as a labelled claim, or has the label added so it becomes visible.
  • #902's current state (assigned, good first issue, no status:claimed) is resolved
    rather than left parked.
  • Every claim is discoverable by at least one of the two signals the docs describe, so the
    "claims lapse" promise in CONTRIBUTING.md holds for both claim shapes.
  • The open-PR exemption and the "never close, never edit the body" safety properties of
    stale-claims.yml are preserved by whatever sweep is added.

Provenance

Found while reviewing #945, which added the no:assignee filter to the good-first-issue
link. The filter is correct and is not the bug; it removed the last thing that made this
state visible. The root cause is in stale-claims.yml, outside that PR, so it is filed
rather than folded in.

Dominant language
TypeScript
Stars
11
Forks
4
Avg merge
1d 15h
Merged PRs (30d)
45

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from offlinecv/OfflineCV

All issues in offlinecv/OfflineCV

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.