An Open Task Is Not Yet a Contribution

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: Was this problem authorized? What files, systems or external actions were inside the boundary? What evidence would prove completion? Which risks required human review? Who is accountable for the result? A useful contributor surface should reveal those constraints before it asks for commitment. Start with problems, not identity collection WebAZ currently exposes a narrow public contribution entry through the full Remote MCP surface. Without an API key, a person or Agent can: list public build tasks; inspect a task's execution boundary and acceptance criteria; submit an evidence-backed suggestion to the maintainer review inbox. 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 cha