IDKMesh is not currently compute-starved or implementation-starved. It is external-attention and first-contact starved.
At approximately 19:05 CEST on 2026-08-28, the repository was only about 4.5 hours old but had already generated hundreds of internal GitHub events, many pull requests, many merges, a large issue surface, multiple deterministic observatories, a Free Resource Mesh, and live experiments.
At the same time, public repository metadata still reported:
The ACE Bootstrap Cohort Observatory reported:
The correct diagnosis is therefore not “build more internal machinery faster.” It is:
internal production >> external discovery >> first-contact conversion
The next growth iteration should spend scarce maintainer/agent effort on increasing the probability that a qualified external person discovers one clear project thesis and one bounded action.
Four explanations are consistent with the evidence.
A few hours is too short to infer that the project cannot attract contributors. Search indexing, social propagation, word of mouth, and contributor scheduling all have latency.
The repository currently lacks a description and topics. Discussions and Pages are disabled. The README is substantial, but it mostly helps after somebody reaches the repository.
Commits, PRs, Actions runs, issue updates, and self-evolution artifacts can improve a repository, but GitHub does not guarantee that high internal event volume will be distributed to relevant external developers. A self-growing system therefore needs explicit public discovery surfaces rather than assuming activity becomes reach.
IDKMesh should not mass-mention strangers, scrape emails, auto-DM people, or manufacture engagement. The repository needs permissionless public surfaces that make useful work discoverable without unsolicited outreach.
The existing registry already records useful zero-project-cost lanes:
These should remain opportunistic resources rather than protocol constants. Every external service must be re-observed for quota/security changes before activation.
A useful new resource/discovery candidate is Hugging Face Spaces ZeroGPU.
Observed from Hugging Face documentation on 2026-08-28:
Authoritative sources:
Most free resources improve only compute. A public Space can improve two dimensions at once:
small bounded GPU experiment
+
public interactive demonstration
->
compute evidence + discovery surface
A first Space should not become a privileged IDKMesh worker or GitHub writer. It should be a read-only/public demonstration, for example:
No repository token, merge authority, private data, or canonical-write authority should be present in the Space.
The repository should optimize a simple conversion funnel:
Discovery D
-> comprehension C
-> bounded-action selection A
-> contribution/claim Q
-> independently verified useful result V
-> return/help-another R
The current failure is near D and C, not V.
Repository owner/admin action:
Tracked in issue #173.
The public front door should expose exactly three paths above the fold:
help wanted task.Do not show dozens of internal architecture links before these actions.
Candidate ordering:
Do not evaluate growth from commits, PR count, comments, stars, or workflow runs.
First milestone:
one non-owner, non-bot external person
-> reaches a public front door
-> asks a concrete question OR claims a bounded task OR submits a bounded candidate
Second milestone:
that first contact becomes an independently verified useful contribution
Third milestone:
that contributor returns or helps another contributor
This creates a causal growth lineage rather than an activity metric.
Define a short-window growth vector:
x_t = [external_visitors_proxy, external_contacts, claims, verified_descendants, returns]
For each public growth experiment i, estimate a Beta posterior for conversion success:
p_i ~ Beta(alpha_i, beta_i)
Update only from externally attributable outcomes, then allocate the next small growth action using Thompson sampling or UCB with a diversity floor.
Example strategies:
good first issue wording;Fitness should be approximately:
verified external descendants + qualified first contacts
--------------------------------------------------------
1 + maintainer_minutes + reviewer_minutes + public_noise
Hard rule:
internal owner/bot activity cannot count as external growth evidence
Use a small number of simultaneous surfaces rather than one surface or dozens:
70% attention -> best current conversion surface
20% -> second-best / diversity-preserving surface
10% -> new experiment
This is an engineering hypothesis to test, not a proven optimal allocation.
Do not accelerate growth by:
Within the next real external-contact window, record:
That evidence is more valuable for community growth than another hundred owner-generated repository events.