> Ok, the title is misleading.  I think that Project Coin is doing great
> work.  I just loved my subsection title so much that I couldn't
> resist. :-)  Besides, it made you look.  If only I can get you to read
> all of this. :-D

> In their interview with Joe Darcy and Alex Buckley, the Java Posse
> raised some very interesting points about the evolution of the Java
> language, the JVM, and the Java language platform (Yes, I do think
> that we should start thinking in terms of a Java language platform,
> but that is another post).  However, they missed some key frustrations
> that are effecting the participation in the open jdk.

> There appears to be some disappointment that there has not been more
> uptake of work on the JVM.  However, I think this can be isolated to
> three specific issues.  There is no mechanism for participation in the
> decision process for what language features are or are not included in
> the in the Java language.  There appears to be a very Sun centric view
> of available resources.  And, there is no mechanism for carving up the
> work on what appears to be significant portions of work to implement
> and test language proposals.

> PARTICIPATION
> Project Coin was a great start.  It was billed as a mechanism to get
> your small language change ideas into the hands of the decision
> makers.  I think that there was a severe mis marketing there, as it is
> clear from the comments that the intention was not to gather the
> ideas, but to gather prototypes for the implementation of ideas.  Even
> at that, there was frustration with how the Project Coin leaders (Joe
> and Alex?) arrived at their choices.  Clearly they were difficult
> decisions and they did the best they could in their choices and to
> explain their decisions.  They can't make everyone happy.  I think,
> however, the approach is flawed.

> First, the mis-marketing could have been solved by some simple web
> site redesign. The web site should go through two phases.  The first,
> should be a process where the ideas are listed.  This could be
> community driven or project team driven.  However, it should clearly
> show (with a separation of lists) the ideas that are under
> consideration and those that are not. All ideas should start as
> proposed, but not under consideration.  The second phase would be the
> work phase.  This phase would provide the mechanism to move the idea
> from proposed state to the under consideration state.  In order to do
> this, the appropriate documentation, prototype implementation, and
> test cases would need to be provided.  For those features where the
> community was not willing to do the work to implement is, this should
> provide a clear delineation of why they were not considered.  It would
> also make it easier for the onlookers to take up the cause and try to
> augment the ideas.  In this latest process, once an idea was proposed
> it felt like there was an expectation that the proposer was
> responsible for the implementation work.  As a result, it didn't feel
> like I (or the other onlookers) could participate in furthering that
> idea.  It was there idea.  In fact, it seemed to foster more of a
> competitive environment (as opposed to cooperative).

> Second, the decision process.  There are two models for difficult
> decisions.  You either use a dictatorship or a democracy.  In this
> case, Project Coin tried to act like a democracy, but ultimately made
> their decisions like a benevolent dictator. As Miyagi said, left side
> of road ok...right side road, ok...middle of road, get quashed.

> This dichotomy is confusing.  Joe and Alex said in their interview,
> "if you have a funnel a mile wide and an inch deep, how do you choose
> what goes through?"  Well, politics 101 is that you make sure you are
> not to blame when someone doesn't get what they want. :)  In all
> seriousness, a voting process is the answer.  Let people vote for the
> language features they want.  Try to prevent them from gaming the
> system, but let them participate.  On each iteration, assign a
> complexity score (let the community participate in setting this as
> well) and figure it against the popularity of the feature.  Have a
> phase where 'no goes' can be evaluated (breaks other features).  If it
> can't be put in because the design/prototype break other parts of the
> language, then put it in a status where it can be later reconsidered.
> This gives the community a chance to fix the problem.  I think I could
> go on and on with this.  However, the point is to let the community
> participate in the decision via a democratic process.

> Obviously, Sun wants to have some say in the features that they want
> to spend their resources on.  Certainly they are entitled to work on
> features that they consider important. It's their money. However, if
> they will commit some resources to help with this work and manage
> these features to a project plan, then they can get open source
> volunteers to be more involved.  As the features reach completion,
> they can get rolled into the next jdk.  If they are not ready when the
> jcp decision is ratified, then it gets considered for the next
> version.  The bottom line is, if the community wants feature X, then
> they need to do the work.  However, the corollary promise is that if
> they do the work, then they will get the feature.

> SUN CENTERED GALAXY
> Joe and Alex seemed to very definitively take the position that we are
> talking about the community trying to dictate the allocation of Sun
> resources. They have a point.  Sun is a company that can make it's own
> decisions about what makes sense for it's resources.  However, those
> that are governing the process for introducing or managing Java
> language changes need to have a larger perspective.

> There are people that would be willing to work on these complex
> problems.  However, it feels, right now that the investment could be
> in vain.  The effort of managing language changes should not be about
> Sun and it's resources.  It should be about managing the list of
> proposals, evaluating the prototypes, managing open source projects to
> do the implementations, and yes...evaluating where to deploy Sun's
> resources among the proposals.  Sure, Sun can choose to work on
> something that is not in the top tier of proposals.  That is fine.
> However, the mechanism for managing what gets in and what does not get
> in should not be built around where Sun is willing to spend it's
> resources.  Simply, it is a difference in perspective that allows the
> community to participate more.

> BLOWING CHUNKS
> Language changes are hard.  The ramifications are large.  The detail
> in the proposals in non trivial.  The prototypes take time.  As with
> other business issues that require too many resources, this is a place
> for technology to be applied.  An app that facilitates breaking the
> changes into smaller chunks, that can be worked on collaboratively, is
> required.  It should allow the proposal to be shared.  Maybe a wiki
> makes the most sense for the proposal.  Maybe something more like
> Wave.  There needs to be a project management component that allows
> the project to be broken into code modules.  It should allow people to
> take on these individual code modules or tasks. It should allow these
> modules to be committed and run through CI.  Fundamentally, it should
> use the best practices that we have established for how to run open
> source software products.  If they can find a way to simplify the
> development for the open jdk.  If they can find a way to break up the
> tasks into weekend sized pieces, then I think that they will find the
> uptake on the work will significantly increase.  Afterall, with all of
> it's complexity, the jvm is not as complex as linux (as

> Your conclusion that coin fostered a modicum of competition rang true
> for me. Given that the emphasis lied very much on: Only a few will
> make it, I really had to stop myself from pointing out the first flaws
> that came to mind for those proposals that I was ambivalent about (but
> not against), just because it felt like that might get in the way of
> the proposals I really wanted to see.

> I've been banging on the drum of: You aren't properly fostering the
> community, which is why you aren't seeing the kind of participation
> you are hoping for, for a while now.

> FWIW, I'm actually in favour of requiring a prototype for a complete
> proposal, a Joe mentioned was at one point the plan for coin '09. Of
> course, there should be more phases, and whomever is the benevolent
> dictator (something that still isn't entirely clear to me - talk about
> miscommunication!!) needs to make earlier calls. Don't hide behind
> "It's complicated". We know that. If you change your mind on something
> you already soft-committed to earlier, we understand there were good
> reasons. But, if someone makes a proposal that you just know is
> unlikely to ever make it through, the earlier you say that, the less
> effort this person wastes. And, as I've said before, wasting your
> communities' time is a fine way of destroying it. (even if you don't
> think people flailing away at proposals that don't cut it and probably
> never will is a waste of time, they surely do, and that's what
> counts!)

> A corrolary to this is that you can reverse the process:

> If sun claims: We are not opposed and would in fact welcome feature
> XYZ, but we just don't have time to add it, then a community of fans
> can come together, build a prototype, a JLS patch, do some research,
> whatever you need. The community is much more willing to put in that
> kind of work if they already know that work will likely be going
> places.

> On Sep 24, 3:53 am, "pub...@lesstroud.com" <stroud....@gmail.com>
> wrote:

> > Ok, the title is misleading.  I think that Project Coin is doing great
> > work.  I just loved my subsection title so much that I couldn't
> > resist. :-)  Besides, it made you look.  If only I can get you to read
> > all of this. :-D

> > In their interview with Joe Darcy and Alex Buckley, the Java Posse
> > raised some very interesting points about the evolution of the Java
> > language, the JVM, and the Java language platform (Yes, I do think
> > that we should start thinking in terms of a Java language platform,
> > but that is another post).  However, they missed some key frustrations
> > that are effecting the participation in the open jdk.

> > There appears to be some disappointment that there has not been more
> > uptake of work on the JVM.  However, I think this can be isolated to
> > three specific issues.  There is no mechanism for participation in the
> > decision process for what language features are or are not included in
> > the in the Java language.  There appears to be a very Sun centric view
> > of available resources.  And, there is no mechanism for carving up the
> > work on what appears to be significant portions of work to implement
> > and test language proposals.

> > PARTICIPATION
> > Project Coin was a great start.  It was billed as a mechanism to get
> > your small language change ideas into the hands of the decision
> > makers.  I think that there was a severe mis marketing there, as it is
> > clear from the comments that the intention was not to gather the
> > ideas, but to gather prototypes for the implementation of ideas.  Even
> > at that, there was frustration with how the Project Coin leaders (Joe
> > and Alex?) arrived at their choices.  Clearly they were difficult
> > decisions and they did the best they could in their choices and to
> > explain their decisions.  They can't make everyone happy.  I think,
> > however, the approach is flawed.

> > First, the mis-marketing could have been solved by some simple web
> > site redesign. The web site should go through two phases.  The first,
> > should be a process where the ideas are listed.  This could be
> > community driven or project team driven.  However, it should clearly
> > show (with a separation of lists) the ideas that are under
> > consideration and those that are not. All ideas should start as
> > proposed, but not under consideration.  The second phase would be the
> > work phase.  This phase would provide the mechanism to move the idea
> > from proposed state to the under consideration state.  In order to do
> > this, the appropriate documentation, prototype implementation, and
> > test cases would need to be provided.  For those features where the
> > community was not willing to do the work to implement is, this should
> > provide a clear delineation of why they were not considered.  It would
> > also make it easier for the onlookers to take up the cause and try to
> > augment the ideas.  In this latest process, once an idea was proposed
> > it felt like there was an expectation that the proposer was
> > responsible for the implementation work.  As a result, it didn't feel
> > like I (or the other onlookers) could participate in furthering that
> > idea.  It was there idea.  In fact, it seemed to foster more of a
> > competitive environment (as opposed to cooperative).

> > Second, the decision process.  There are two models for difficult
> > decisions.  You either use a dictatorship or a democracy.  In this
> > case, Project Coin tried to act like a democracy, but ultimately made
> > their decisions like a benevolent dictator. As Miyagi said, left side
> > of road ok...right side road, ok...middle of road, get quashed.

> > This dichotomy is confusing.  Joe and Alex said in their interview,
> > "if you have a funnel a mile wide and an inch deep, how do you choose
> > what goes through?"  Well, politics 101 is that you make sure you are
> > not to blame when someone doesn't get what they want. :)  In all
> > seriousness, a voting process is the answer.  Let people vote for the
> > language features they want.  Try to prevent them from gaming the
> > system, but let them participate.  On each iteration, assign a
> > complexity score (let the community participate in setting this as
> > well) and figure it against the popularity of the feature.  Have a
> > phase where 'no goes' can be evaluated (breaks other features).  If it
> > can't be put in because the design/prototype break other parts of the
> > language, then put it in a status where it can be later reconsidered.
> > This gives the community a chance to fix the problem.  I think I could
> > go on and on with this.  However, the point is to let the community
> > participate in the decision via a democratic process.

> > Obviously, Sun wants to have some say in the features that they want
> > to spend their resources on.  Certainly they are entitled to work on
> > features that they consider important. It's their money. However, if
> > they will commit some resources to help with this work and manage
> > these features to a project plan, then they can get open source
> > volunteers to be more involved.  As the features reach completion,
> > they can get rolled into the next jdk.  If they are not ready when the
> > jcp decision is ratified, then it gets considered for the next
> > version.  The bottom line is, if the community wants feature X, then
> > they need to do the work.  However, the corollary promise is that if
> > they do the work, then they will get the feature.

> > SUN CENTERED GALAXY
> > Joe and Alex seemed to very definitively take the position that we are
> > talking about the community trying to dictate the allocation of Sun
> > resources. They have a point.  Sun is a company that can make it's own
> > decisions about what makes sense for it's resources.  However, those
> > that are governing the process for introducing or managing Java
> > language changes need to have a larger perspective.

> > There are people that would be willing to work on these complex
> > problems.  However, it feels, right now that the investment could be
> > in vain.  The effort of managing language changes should not be about
> > Sun and it's resources.  It should be about managing the list of
> > proposals, evaluating the prototypes, managing open source projects to
> > do the implementations, and yes...evaluating where to deploy Sun's
> > resources among the proposals.  Sure, Sun can choose to work on
> > something that is not in the top tier of proposals.  That is fine.
> > However, the mechanism for managing what gets in and what does not get
> > in should not be built around where Sun is willing to spend it's
> > resources.  Simply, it is a difference in perspective that allows the
> > community to participate more.

> > BLOWING CHUNKS
> > Language changes are hard.  The ramifications are large.  The detail
> > in the proposals in non trivial.  The prototypes take time.  As with
> > other business issues that require too many resources, this is a place
> > for technology to be applied.  An app that facilitates breaking the
> > changes into smaller chunks, that can be worked on collaboratively, is
> > required.  It

> I think like Reinier and Les that Sun could do more to foster the
> community. All the suggestions from Les and Reinier are good,
> particularly the concept of putting together a list of ideas which Sun
> don't have as their priorities but would give some lower level of
> support to if someone else did the implementation. In particular, if
> they would commit to enthusiastically push for inclusion of idea X
> into Java if a working and production quality prototype of X was
> available.

> On Sep 24, 4:19 am, Reinier Zwitserloot <reini...@gmail.com> wrote:

> > Your conclusion that coin fostered a modicum of competition rang true
> > for me. Given that the emphasis lied very much on: Only a few will
> > make it, I really had to stop myself from pointing out the first flaws
> > that came to mind for those proposals that I was ambivalent about (but
> > not against), just because it felt like that might get in the way of
> > the proposals I really wanted to see.

> > I've been banging on the drum of: You aren't properly fostering the
> > community, which is why you aren't seeing the kind of participation
> > you are hoping for, for a while now.

> > FWIW, I'm actually in favour of requiring a prototype for a complete
> > proposal, a Joe mentioned was at one point the plan for coin '09. Of
> > course, there should be more phases, and whomever is the benevolent
> > dictator (something that still isn't entirely clear to me - talk about
> > miscommunication!!) needs to make earlier calls. Don't hide behind
> > "It's complicated". We know that. If you change your mind on something
> > you already soft-committed to earlier, we understand there were good
> > reasons. But, if someone makes a proposal that you just know is
> > unlikely to ever make it through, the earlier you say that, the less
> > effort this person wastes. And, as I've said before, wasting your
> > communities' time is a fine way of destroying it. (even if you don't
> > think people flailing away at proposals that don't cut it and probably
> > never will is a waste of time, they surely do, and that's what
> > counts!)

> > A corrolary to this is that you can reverse the process:

> > If sun claims: We are not opposed and would in fact welcome feature
> > XYZ, but we just don't have time to add it, then a community of fans
> > can come together, build a prototype, a JLS patch, do some research,
> > whatever you need. The community is much more willing to put in that
> > kind of work if they already know that work will likely be going
> > places.

> > On Sep 24, 3:53 am, "pub...@lesstroud.com" <stroud....@gmail.com>
> > wrote:

> > > Ok, the title is misleading.  I think that Project Coin is doing great
> > > work.  I just loved my subsection title so much that I couldn't
> > > resist. :-)  Besides, it made you look.  If only I can get you to read
> > > all of this. :-D

> > > In their interview with Joe Darcy and Alex Buckley, the Java Posse
> > > raised some very interesting points about the evolution of the Java
> > > language, the JVM, and the Java language platform (Yes, I do think
> > > that we should start thinking in terms of a Java language platform,
> > > but that is another post).  However, they missed some key frustrations
> > > that are effecting the participation in the open jdk.

> > > There appears to be some disappointment that there has not been more
> > > uptake of work on the JVM.  However, I think this can be isolated to
> > > three specific issues.  There is no mechanism for participation in the
> > > decision process for what language features are or are not included in
> > > the in the Java language.  There appears to be a very Sun centric view
> > > of available resources.  And, there is no mechanism for carving up the
> > > work on what appears to be significant portions of work to implement
> > > and test language proposals.

> > > PARTICIPATION
> > > Project Coin was a great start.  It was billed as a mechanism to get
> > > your small language change ideas into the hands of the decision
> > > makers.  I think that there was a severe mis marketing there, as it is
> > > clear from the comments that the intention was not to gather the
> > > ideas, but to gather prototypes for the implementation of ideas.  Even
> > > at that, there was frustration with how the Project Coin leaders (Joe
> > > and Alex?) arrived at their choices.  Clearly they were difficult
> > > decisions and they did the best they could in their choices and to
> > > explain their decisions.  They can't make everyone happy.  I think,
> > > however, the approach is flawed.

> > > First, the mis-marketing could have been solved by some simple web
> > > site redesign. The web site should go through two phases.  The first,
> > > should be a process where the ideas are listed.  This could be
> > > community driven or project team driven.  However, it should clearly
> > > show (with a separation of lists) the ideas that are under
> > > consideration and those that are not. All ideas should start as
> > > proposed, but not under consideration.  The second phase would be the
> > > work phase.  This phase would provide the mechanism to move the idea
> > > from proposed state to the under consideration state.  In order to do
> > > this, the appropriate documentation, prototype implementation, and
> > > test cases would need to be provided.  For those features where the
> > > community was not willing to do the work to implement is, this should
> > > provide a clear delineation of why they were not considered.  It would
> > > also make it easier for the onlookers to take up the cause and try to
> > > augment the ideas.  In this latest process, once an idea was proposed
> > > it felt like there was an expectation that the proposer was
> > > responsible for the implementation work.  As a result, it didn't feel
> > > like I (or the other onlookers) could participate in furthering that
> > > idea.  It was there idea.  In fact, it seemed to foster more of a
> > > competitive environment (as opposed to cooperative).

> > > Second, the decision process.  There are two models for difficult
> > > decisions.  You either use a dictatorship or a democracy.  In this
> > > case, Project Coin tried to act like a democracy, but ultimately made
> > > their decisions like a benevolent dictator. As Miyagi said, left side
> > > of road ok...right side road, ok...middle of road, get quashed.

> > > This dichotomy is confusing.  Joe and Alex said in their interview,
> > > "if you have a funnel a mile wide and an inch deep, how do you choose
> > > what goes through?"  Well, politics 101 is that you make sure you are
> > > not to blame when someone doesn't get what they want. :)  In all
> > > seriousness, a voting process is the answer.  Let people vote for the
> > > language features they want.  Try to prevent them from gaming the
> > > system, but let them participate.  On each iteration, assign a
> > > complexity score (let the community participate in setting this as
> > > well) and figure it against the popularity of the feature.  Have a
> > > phase where 'no goes' can be evaluated (breaks other features).  If it
> > > can't be put in because the design/prototype break other parts of the
> > > language, then put it in a status where it can be later reconsidered.
> > > This gives the community a chance to fix the problem.  I think I could
> > > go on and on with this.  However, the point is to let the community
> > > participate in the decision via a democratic process.

> > > Obviously, Sun wants to have some say in the features that they want
> > > to spend their resources on.  Certainly they are entitled to work on
> > > features that they consider important. It's their money. However, if
> > > they will commit some resources to help with this work and manage
> > > these features to a project plan, then they can get open source
> > > volunteers to be more involved.  As the features reach completion,
> > > they can get rolled into the next jdk.  If they are not ready when the
> > > jcp decision is ratified, then it gets considered for the next
> > > version.  The bottom line is, if the community wants feature X, then
> > > they need to do the work.  However, the corollary promise is that if
> > > they do the work, then they will get the feature.

> > > SUN CENTERED GALAXY
> > > Joe and Alex seemed to very definitively take the position that we are
> > > talking about the community trying to dictate the allocation of Sun
> > > resources. They have a point.  Sun is a company that can make it's own
> > > decisions about what makes sense for it's resources.  However, those
> > > that are governing the process for introducing or managing Java
> > > language changes need to have a larger perspective.

> > > There are people that would be willing to work on these complex
> > > problems.  However, it feels, right now that the investment could be
> > > in vain.  The effort of managing language changes should not be about
> > > Sun and it's resources.  It should be about managing the list of
> > > proposals, evaluating the prototypes, managing open source projects to
> > > do the implementations, and yes...evaluating where to deploy Sun's
> > > resources among

> That's roughly what I communicated to Alex Buckley as well when he
> asked me. There was very little practical guidance (I piggy-bagged on
> Kijaro) except for a mailinglist with the usual elite people (Forax,
> Gafter, Bloch etc.). My guess is though that an eventual JDK8 go-round
> will have learned from Coin. My fear is just that the people with
> enough skill will have moved on to greener pastures or adopted other
> strategies of innovating (i.e. Lombok).

> /Casper

> On 24 Sep., 15:16, hlovatt <howard.lov...@gmail.com> wrote:

> > I think like Reinier and Les that Sun could do more to foster the
> > community. All the suggestions from Les and Reinier are good,
> > particularly the concept of putting together a list of ideas which Sun
> > don't have as their priorities but would give some lower level of
> > support to if someone else did the implementation. In particular, if
> > they would commit to enthusiastically push for inclusion of idea X
> > into Java if a working and production quality prototype of X was
> > available.

> > On Sep 24, 4:19 am, Reinier Zwitserloot <reini...@gmail.com> wrote:

> > > Your conclusion that coin fostered a modicum of competition rang true
> > > for me. Given that the emphasis lied very much on: Only a few will
> > > make it, I really had to stop myself from pointing out the first flaws
> > > that came to mind for those proposals that I was ambivalent about (but
> > > not against), just because it felt like that might get in the way of
> > > the proposals I really wanted to see.

> > > I've been banging on the drum of: You aren't properly fostering the
> > > community, which is why you aren't seeing the kind of participation
> > > you are hoping for, for a while now.

> > > FWIW, I'm actually in favour of requiring a prototype for a complete
> > > proposal, a Joe mentioned was at one point the plan for coin '09. Of
> > > course, there should be more phases, and whomever is the benevolent
> > > dictator (something that still isn't entirely clear to me - talk about
> > > miscommunication!!) needs to make earlier calls. Don't hide behind
> > > "It's complicated". We know that. If you change your mind on something
> > > you already soft-committed to earlier, we understand there were good
> > > reasons. But, if someone makes a proposal that you just know is
> > > unlikely to ever make it through, the earlier you say that, the less
> > > effort this person wastes. And, as I've said before, wasting your
> > > communities' time is a fine way of destroying it. (even if you don't
> > > think people flailing away at proposals that don't cut it and probably
> > > never will is a waste of time, they surely do, and that's what
> > > counts!)

> > > A corrolary to this is that you can reverse the process:

> > > If sun claims: We are not opposed and would in fact welcome feature
> > > XYZ, but we just don't have time to add it, then a community of fans
> > > can come together, build a prototype, a JLS patch, do some research,
> > > whatever you need. The community is much more willing to put in that
> > > kind of work if they already know that work will likely be going
> > > places.

> > > On Sep 24, 3:53 am, "pub...@lesstroud.com" <stroud....@gmail.com>
> > > wrote:

> > > > Ok, the title is misleading.  I think that Project Coin is doing great
> > > > work.  I just loved my subsection title so much that I couldn't
> > > > resist. :-)  Besides, it made you look.  If only I can get you to read
> > > > all of this. :-D

> > > > In their interview with Joe Darcy and Alex Buckley, the Java Posse
> > > > raised some very interesting points about the evolution of the Java
> > > > language, the JVM, and the Java language platform (Yes, I do think
> > > > that we should start thinking in terms of a Java language platform,
> > > > but that is another post).  However, they missed some key frustrations
> > > > that are effecting the participation in the open jdk.

> > > > There appears to be some disappointment that there has not been more
> > > > uptake of work on the JVM.  However, I think this can be isolated to
> > > > three specific issues.  There is no mechanism for participation in the
> > > > decision process for what language features are or are not included in
> > > > the in the Java language.  There appears to be a very Sun centric view
> > > > of available resources.  And, there is no mechanism for carving up the
> > > > work on what appears to be significant portions of work to implement
> > > > and test language proposals.

> > > > PARTICIPATION
> > > > Project Coin was a great start.  It was billed as a mechanism to get
> > > > your small language change ideas into the hands of the decision
> > > > makers.  I think that there was a severe mis marketing there, as it is
> > > > clear from the comments that the intention was not to gather the
> > > > ideas, but to gather prototypes for the implementation of ideas.  Even
> > > > at that, there was frustration with how the Project Coin leaders (Joe
> > > > and Alex?) arrived at their choices.  Clearly they were difficult
> > > > decisions and they did the best they could in their choices and to
> > > > explain their decisions.  They can't make everyone happy.  I think,
> > > > however, the approach is flawed.

> > > > First, the mis-marketing could have been solved by some simple web
> > > > site redesign. The web site should go through two phases.  The first,
> > > > should be a process where the ideas are listed.  This could be
> > > > community driven or project team driven.  However, it should clearly
> > > > show (with a separation of lists) the ideas that are under
> > > > consideration and those that are not. All ideas should start as
> > > > proposed, but not under consideration.  The second phase would be the
> > > > work phase.  This phase would provide the mechanism to move the idea
> > > > from proposed state to the under consideration state.  In order to do
> > > > this, the appropriate documentation, prototype implementation, and
> > > > test cases would need to be provided.  For those features where the
> > > > community was not willing to do the work to implement is, this should
> > > > provide a clear delineation of why they were not considered.  It would
> > > > also make it easier for the onlookers to take up the cause and try to
> > > > augment the ideas.  In this latest process, once an idea was proposed
> > > > it felt like there was an expectation that the proposer was
> > > > responsible for the implementation work.  As a result, it didn't feel
> > > > like I (or the other onlookers) could participate in furthering that
> > > > idea.  It was there idea.  In fact, it seemed to foster more of a
> > > > competitive environment (as opposed to cooperative).

> > > > Second, the decision process.  There are two models for difficult
> > > > decisions.  You either use a dictatorship or a democracy.  In this
> > > > case, Project Coin tried to act like a democracy, but ultimately made
> > > > their decisions like a benevolent dictator. As Miyagi said, left side
> > > > of road ok...right side road, ok...middle of road, get quashed.

> > > > This dichotomy is confusing.  Joe and Alex said in their interview,
> > > > "if you have a funnel a mile wide and an inch deep, how do you choose
> > > > what goes through?"  Well, politics 101 is that you make sure you are
> > > > not to blame when someone doesn't get what they want. :)  In all
> > > > seriousness, a voting process is the answer.  Let people vote for the
> > > > language features they want.  Try to prevent them from gaming the
> > > > system, but let them participate.  On each iteration, assign a
> > > > complexity score (let the community participate in setting this as
> > > > well) and figure it against the popularity of the feature.  Have a
> > > > phase where 'no goes' can be evaluated (breaks other features).  If it
> > > > can't be put in because the design/prototype break other parts of the
> > > > language, then put it in a status where it can be later reconsidered.
> > > > This gives the community a chance to fix the problem.  I think I could
> > > > go on and on with this.  However, the point is to let the community
> > > > participate in the decision via a democratic process.

> > > > Obviously, Sun wants to have some say in the features that they want
> > > > to spend their resources on.  Certainly they are entitled to work on
> > > > features that they consider important. It's their money. However, if
> > > > they will commit some resources to help with this work and manage
> > > > these features to a project plan, then they can get open source
> > > > volunteers to be more involved.  As the features reach completion,
> > > > they can get rolled into the next jdk.  If they are not ready when the
> > > > jcp decision is ratified, then it gets considered for the next
> > > > version.  The bottom line is, if the community wants feature X, then
> > > > they need to do the work.  However, the corollary promise is that if
> > > > they do the work, then they will get the feature.

> > > > SUN CENTERED GALAXY
> > > > Joe and Alex seemed to very definitively take the position that we are
> > > > talking about the community