I was ever so slightly ahead of you on that one:
I'm going to put up a skeleton based on the discussions so far, and I
was actually planning to do that before mentioning the URL. However,
since you brought it up, I'll post the URL now. There's nothing there
right now, but there will be this evening.
> Alternate ideas/proposals for various things (like say, how to do
> module/resource loading) could be written up on a wiki page (which
> could include pointers to existing projects out there), and then they
> could be discussed/voted on.
Yes, my thoughts exactly.
> Apart from that, I just wanted to kick off a discussion about how
> we're actually going to go about this.
Right now, I think we can play things pretty loose, because we're all
in a sort of information gathering stage. I think pretty soon, we'll
start having concrete proposals for things and we'll need to have a
bit of process, so it's not unreasonable to have thoughts on process
as part of the information gathering stage.
There is a distinct danger of not accomplishing anything, and I hope
we can get over that hurdle. Unlike Python, we have no benevolent
dictator. There are already more than 100 people on this list. That's
a lot of opinions to reconcile to ultimately produce code.
Design-by-committee often produces terrible results as well, so that's
something else to look out for.
And one more danger is "death by spiraling" as arguments go on
endlessly about what color the bikeshed should be. In software,
everything has tradeoffs and very often two choices are roughly
equivalent but have different feels. A dictator provides an easy way
to cut off discussion. Voting can as well.
And, at the end of it all, we want to have something we can *use* and
run for real life projects. It doesn't matter if we come up with the
ultimate File object if it never gets implemented. In the world of
open source, code speaks louder than words.
I'm thinking that we'll likely end up with some sort of process that
involves proposals and counter proposals, voting *and* people taking
on the dictator role for certain parts of the whole that they're very
committed to (ie are willing to take the lead on getting the code
That's all capped with a big IMHO. I'm open to any usable process that
ultimately produces something I can build apps with :)
Personally, I like email for discussing things (IRC can be good when
you need more back-and-forth and, of course, face-to-face is the
I especially like email with a good archive, like googlegroups. The
wiki is a good place to boil down the discussions into something
> b) How about being the benevolent dictator? You're obviously already
> benevolent, since you started this list. :) OK, so that's settled. Kevin is
> final stop if we disagree.
I'm willing to help break deadlocks, if people want me to. My hope is
that we'd have people take charge of specific areas and act as
dictator there to make sure that things don't get stuck.
>> b) How about being the benevolent dictator? You're obviously already
>> benevolent, since you started this list. :) OK, so that's settled. Kevin is
>> final stop if we disagree.
> I'm willing to help break deadlocks, if people want me to. My hope is
> that we'd have people take charge of specific areas and act as
> dictator there to make sure that things don't get stuck.
Benevolent dictator works if there is a canonical implementation
written and updated by the dictator. If all this group will produce is
a spec then it is mostly begging implementers to conform. A dictator
here cannot force implementers to conform. Without the implementer's
agreement the spec is worthless. I believe this is why ECMAScript is
designed by consensus committee. If everyone feels like they had their
say and were heard then the open web will benefit as everyone will
implement the spec.
This is absolutely true.
> I believe this is why ECMAScript is
> designed by consensus committee. If everyone feels like they had their
> say and were heard then the open web will benefit as everyone will
> implement the spec.
Luckily, we have things better than in the world of ECMAScript. In the
case of ECMAScript, the implementation *and* distribution were both
locked up. If Microsoft decides they don't like something, they can
completely kill it by just not implementing it in IE. With open
source, even if one person disagrees with a path that is being taken,
others can pick it up and keep the implementation moving forward.
But, your point is spot on: the people implementing the APIs
necessarily have more say than anyone else.
Implementers naturally have more influence than others, but that
doesn't mean we can't have a benevolent dictator breaking deadlocks on
the specification. Everyone should come to the table that for the
purposes of this group consensus is the position that produces the
lowest level of objection, it isn't everyone agreeing (that would be
unanimity). Typically what happens is that you win some and you lose
some, but the value of reaching agreement is superior to that of the
arguments you lose.