ServerJS/ProposalProcess

STATE: DISCUSSION

We adopt a JFDI policy regarding adding proposals to CommonJS.

As long as the page makes the level of acceptance clear with a line at the top, it's not a problem.

State 1: "Proposed"

"Hay guys, I have an idea for a topic!"

Don't say it, just do it. Add a page to the wiki describing your proposal.

Bonus points if you can point at working code. It's not always prudent to implement something complicated before discussing with the group, since it might be misguided and difficult, but at the very least, rough sketch/prototype/proof of concept often helps crystallize the discussion.

Congratulations. You own the idea now. You're responsible for maintaining the wiki page, counting votes, starting the discussion, etc.

If it's not worth it to you to do the work, then it's probably not important enough to be in the spec. This ensures that all ideas need to get over a bit of a hump to get accepted.

State 2: "Discussion"

"Let's talk about my idea!"

Send a message to CommonJS with a link to the wiki page. We'll talk about it, build all kinds of bike sheds.

This should last at least a few days, or however long necessary to flesh out any dissenting opinions. People start weighing in with their votes.

If you have an opinion, share it now. If you don't care one way or the other, then stay out of it.

Silence is not consent.

Some discussion must occur for the idea to progress to "official accepted" status. If someone suggests something, and no one responds, then the idea remains open indefinitely.

If you suggest something, and no one else speaks up in favor of it, that doesn't mean it's a bad idea. However, this is probably something that you should just put in your own application, and it most likely does not belong in the CommonJS specification. This bit of inertia prevents us from building specifications no one wants.

The flip side of this: if someone suggests something, and you think it's a good idea, Speak up!

Unanimity is Suspect

There may be cases when everyone involved in the discussion is in favor of the proposal. This probably means that someone's voice isn't being heard.

In the case of a completely one-sided discussion, make some effort to figure out who might be against it, and try to ping them directly, or at least wait until they weigh in on it before considering the issue closed. It could be that they didn't feel strongly in the first place, or that they've been swayed by the arguments from the other side. But there was probably a reason for their initial resistance, and it should be heard.

State 3: "Decided"

"We're talking in circles and here are the major ideas:..."

Someone count the votes, and we make a decision. Update the wiki page to the latest decision.

Note that a simple vote count doesn't necessarily imply a decision. If 15 people decide that it's a good idea to do something, and the 2 people who maintain that code rebut with valid reasons why it's impossible or impractical, then the 2 should outweigh the 15, and perhaps propose some kind of alternative to meet their needs.

State 4: "Implemented"

At least a handful of the relevant projects have implemented the spec. Add links to implementations to the wiki page. At this point, it's considered final, and can only be changed by restarting this process.

A proposal only reaches this state by virtue of being implemented in more than one library. At this point, it is considered a standard, and implementers can rest assured that it will not change without good reason.