Open Contribution — Current Bet #1: Ideas in Discussions, executable work in Issues

[lfnovo]

We are changing how contributions enter Open Notebook.

Until now, feature requests and open-ended proposals could enter the same Issue tracker as bugs and work that was already ready to execute. That made very different states look like the same thing: a problem worth exploring, a direction still needing a product or design decision, and a task the project had actually committed to deliver.

As code becomes cheaper to produce, that ambiguity becomes more expensive. An Issue can look like permission to implement before we have agreed on the problem, the trade-offs, or what a successful outcome would be.

Our current bet

Exploration should happen in Discussions. An Issue should represent a reproducible problem or an explicit commitment to executable work.

We believe this separation will give contributors a clearer entry point, help the community participate before implementation, and give maintainers better context for decisions—without turning every idea into an obligation.

This is a hypothesis, not a finished framework. It is useful only if the additional context is worth the coordination cost.

What changed

• PR #1205 removed the Feature Request Issue form and added a structured Ideas Discussion form.
• The new form starts with the contributor's goal, current friction, and desired outcome. Proposed implementations are welcome, but optional.
• The Issue chooser now directs feature requests, product/design/architecture ideas, and contribution proposals to Discussions.
• Public Issues are now for reproducible bugs, diagnosable installation failures, and maintainer-approved work items.
• Our Discussions welcome page now explains the path from exploration to execution.

Scope of this experiment

For now, we are changing the intake for new contributions.

We are not bulk-migrating the historical Issue backlog yet. Existing needs-vision and needs-design Issues remain in place while we observe whether the new entry path works. If it does, a small historical sample may become a later part of this beat.

We are also not assuming that every Discussion should become an Issue. Valid outcomes include accepting, experimenting, parking, declining, or combining a proposal with an existing direction.

Starting point

At launch, the repository had 94 open Issues:

• 59 labeled enhancement;
• 67 labeled needs-design;
• 6 labeled needs-vision;
• 11 labeled ready.

These labels overlap, so the numbers should not be added together. They are a snapshot of how exploration, design uncertainty, and executable work currently coexist in the Issue tracker—not proof that Discussions will solve the problem.

What we will observe

Over the next two weeks, we will look for:

• Routing clarity: Do new ideas arrive in Discussions? How often do maintainers need to move or redirect an entry?
• Context quality: Does the structured form make the goal, current friction, and desired outcome clearer before implementation is discussed?
• Maintainer effort: Does triage become easier, or have we merely moved and expanded the coordination work?
• Premature implementation: Do contributors still begin substantial work before the project has accepted and scoped it?
• Graduation quality: When a Discussion becomes an Issue, is the resulting work item clearer and more executable?
• Participation and visibility: Do useful ideas attract use cases and counterexamples, or do they become less visible and stall?

What would change our mind

We should modify or reverse this change if contributors consistently cannot find the right entry point, if Discussions accumulate without decisions, if the additional context does not improve Issue quality, or if maintainer workload grows more than the value created.

How to participate

• If you have a product, feature, design, architecture, or contribution idea, try the new Ideas form.
• If you encounter a reproducible bug or diagnosable installation failure, use the Issue chooser.
• If you maintain or contribute to another open-source project, share where a Discussions-first workflow helped—or where it became bureaucracy, limbo, or lost signal.
• If any part of the routing feels confusing, tell us where you expected to go instead.

This is not a vote. The community can help shape and challenge the direction; maintainers remain accountable for the commitments the project makes.

We will add observations to this Discussion as the experiment runs. On August 5, 2026, we will record a decision: keep, modify, or revert—and explain what we learned.

[lfnovo]

Decision: keep

We committed to recording a decision on August 5 and are doing it 11 days late — worth being honest about, since the weakest signal of this experiment applies to this very Discussion (more below).

What we observed (July 23 → August 16)

• Routing worked. 10 new ideas arrived through the Ideas form. Every new Issue opened in the period was either a reproducible bug or a maintainer-approved work item — not a single feature request had to be redirected out of the Issue tracker.
• Context quality improved. Ideas now arrive with the goal / current friction / desired outcome structure, which makes them noticeably easier to evaluate than the old feature-request Issues.
• Deliberation is not happening yet. Most Ideas Discussions sit at zero replies — and so does this one. Ideas arrive well-formed, but conversations don't yet form around them. Routing alone doesn't create participation; it only creates the space for it.
• Maintainer effort did not grow. The split removed ambiguity about what an Issue means, and triage of the Issue tracker itself got simpler.

What we conclude

The bet's core hypothesis held: separating exploration from execution gave contributors a clearer entry point and kept the Issue tracker meaningful. We are keeping the split.

The thin deliberation is the honest counterweight — and it is exactly what the next stage of this system is meant to address: facilitation, synthesis, and explicit statuses so that Discussions become conversations with outcomes rather than a parking lot.

Next

We've published the bigger picture this bet belongs to — the full contribution system we want to build toward, including the open questions we'd like input on: Open Contribution — The Bigger Picture.

Future changes will follow the same pattern as this one: numbered, observable bets with explicit criteria and a decision date.

[lfnovo]

Bet #2 is live: every idea gets a qualified response — addressing the thin-deliberation signal recorded in the keep decision above. Decision date: September 15, 2026.