Most contributor onboarding starts by collecting identity.
Create an account. Join the community. Request repository access. Pick an issue. Only then discover whether the work is relevant, bounded or even ready to be attempted.
That sequence is especially awkward in AI-assisted development. An Agent can produce a plausible patch quickly, but speed does not answer the questions that maintainers actually need resolved:
A useful contributor surface should reveal those constraints before it asks for commitment.
WebAZ currently exposes a narrow public contribution entry through the full Remote MCP surface.
Without an API key, a person or Agent can:
The conceptual flow looks like this:
discover public task
-> inspect boundary and verification
-> decide whether the problem is understood
-> submit a structured suggestion
-> maintainer review
The default buyer-facing MCP surface does not advertise the contribution tool. The full surface exposes webaz_contribute
, where list_open
, detail
and suggest
are public starting actions.
A compact interaction can begin with:
{
"action": "list_open",
"area": "docs",
"agent_capabilities": "markdown,read-source"
}
The result is not merely a title list. A task can describe risk level, required capabilities, autonomy, estimated effort, context size, dependencies, blocking conditions and whether human review is required.
Before doing anything, a prospective participant can ask for the detail view:
{
"action": "detail",
"task_id": "<public-task-id>"
}
That is where a real coordination system should state what may change, what must not change, what commands or evidence are expected and what “done” means.
The next distinction prevents the public entry point from becoming a participation factory.
A suggestion is a proposal in a maintainer review inbox. It is not:
That weaker status is useful. It allows a newcomer to add signal without pretending that every idea has already created value for the project.
A good suggestion should still carry enough structure to be evaluated:
{
"action": "suggest",
"title": "Add a reproducible empty-state example for the public catalog",
"summary": "The current guide shows successful search but not the expected zero-result contract. Add one exact request, response and verification note.",
"expected_outcome": "A reader can distinguish an honest empty result from a transport or authentication failure.",
"source_ref": "https://example.com/reproduction-note"
}
This example is illustrative. A real suggestion should link only to evidence the proposer is authorized to share.
The WebAZ production core repository is private. Source access and code contributions are invitation-based.
That means the public contribution surface must not imply an open repository or promise that a suggestion will turn into code access. Public discovery and proposal are the available first steps. Maintainers decide whether a proposal needs clarification, should be converted into a task or belongs outside the current scope.
This is less permissive than a public issue tracker, but it is more precise about what the system can promise today.
It also creates a safer role for Agents. An Agent can discover a bounded problem, compare its capabilities with the task requirements, assemble public evidence and draft a suggestion. It cannot independently become the accountable contributor. Invited AI-assisted code contributions must still be triggered by a Passkey-bound human who accepts responsibility for the work.
An open-task system becomes useful when it helps prevent collisions and mis-scoped work.
For Agent-assisted collaboration, I would expect at least these fields:
{
"risk_level": "low",
"required_capabilities": ["markdown", "read-source"],
"agent_autonomy": "autonomous",
"estimated_context_size": "small",
"human_review_required": false,
"dependencies": [],
"blocking_conditions": [],
"value_state": "uncommitted"
}
The final field matters. A task estimate describes effort, not payment. A task record or suggestion should not be interpreted as an economic instrument or a promise of future value.
Before adding another signup form or “good first issue” label, test the entry point with five questions:
The goal is not zero friction. Trustworthy collaboration needs review, identity and responsibility at the right moments.
The goal is to delay those demands until the participant understands the problem, while keeping every later status honest.
For WebAZ, that begins with public task discovery and evidence-backed suggestions. No account is required to understand the work. Acceptance still has to be earned.
WebAZ entry: https://webaz.xyz