Proposals & Mini Specs
What to build, how it will be built, and managing resources as it is built are all discrete problems. This is a suggestion for how we might manage the “What to build” part.
Working on the assumption that the lifecycle of an idea is as follows:
- someone has a brilliant idea; idea phase
- its discussed ad nauseum; idea phase
- the idea is run by the TAG to make sure its feasible; proposal phase
- the idea is turned into a semi-formal spec for development; mini-spec phase
- somebody builds the feature (QA, etc); mini-spec phase
Keep discussions in the forum and not in JIRA.
Someone has a crazy idea. Put it up on the lang forum, and discuss.
Hooray! We’re doing this already.
Eventually the edges will be knocked off and the community will distill a decent summary from those for and against the concept. If the idea still has legs, it needs to enter a more formal process.
Note many ideas will just be that, and never proceed beyond an interesting discussion.
An idea that has survived a robust discussion on the forum needs be turned into a Proposal.
The purpose of the Proposal is to distill a considered request from the community that the Technical Advisory Group (TAG) can comment on. A Proposal can cover any change in the server or underlying language.
The proposal should follow a basic template format (such as https://bugs.openjdk.java.net/browse/JDK-8046186), and embody a neutral statement of the feature with any pros and cons clearly articulated. It doesn’t need to be pulitzer prize winning; it just needs to be concise and unambiguous.
Proposals might only be created by users on the forum with a “trust level” of Regular, but anyone can reply to a proposal. Proposals would sit within their own sub-category, and would be editable WIKI posts. Discussion on proposals should be restricted to the clarification of the proposal only, not more belly-aching about the idea itself.
Replies that are more argumentative, can be moved to the original idea thread/topic. Replies that add to the Proposal may be moved into the WIKI post for clarity and hidden.
Proposals can then be formally reviewed by the TAG, and commented on.
Mini spec phase
Proposals that have passed community scrutiny and deemed viable by the TAG are “ready to build” and will become “mini specs”.
Calling them “mini specs” to set expectations about what’s suitable here; it should be anything that is a positive contribution to the server or language, even if its a relatively small change.
Specs get moved to their own sub-category by an admin or TAG rep. Further discussion on a spec should centre around coordinating efforts to build the agreed functionality.
Specs may or may not be picked up by LAS to build out of its limited development budget. Other development teams may want to coordinate with the core committers to submit a pull request for a new feature.
Having an agreed spec gives us all some clarity on what could be built. And the ability to better coordinate a wider group of committers. It also gives us an opportunity to better “sponsor” specific features, whether that is LAS or another party providing the resources.