Your complaints about community whining (defined as: People who want
language changes but do not offer to do the work) is entirely
justified.

Where coin went a bit wrong, I think, is in how you required more work
from the community than what you require internally. I presume when
(outside of coin) sun employees decide on java features to add to the
language, they first do some analysis of which ones are worth it, pick
one, nail down with decent certainty that this feature WILL be in the
next release, and only then do the work of writing up specs and
prototypes.

Coin asked the reverse: While knowing that the odds of being accepted
are slim to none, do the work anyway.

I'm not surprised coin didn't work as well as you think it might have.
Asking people to waste time isn't very nurturing, with all due respect
of the awesomeness of being able to work on something as momentous as
the java language.

I've said it before, but for the next coin: Accept pre-proposals, and
do your feature selection off of those, with the understanding that an
accepted pre-proposal can still be cancelled at any time if either of
the following happens:

(1) - laziness rule: author of pre-proposal, nor anyone else in the
community, comes up with a spec and a prototype in the alloted time-
frame.

(2) - Surprise rule: while speccing out the proposal or implementing a
prototype, new issues come up that nobody thought of when the pre-
proposal was accepted.

(3) - overbooking rule: If there are just too many complete proposals
that had also been accepted as pre-proposals out there to overwhelm
the larger java community, your proposal will be put on file for the
next release and reconsidered then. Cancelling more than about half of
all full proposals that passed rule #1 and #2 would probably kill your
community, though technically if you get this far, the community can
handle some disappointment. This year's coin certainly didn't. Also,
because some pre-proposals are bound to fall by the wayside due to the
laziness or surprise rule, more pre-proposals should make it through
than you're actually willing to accept into java. In the unlikely even
they all survive, a few would have to be put on ice until the next
java release as well.


It seems that you're discovering that the community capable of putting
in the rigor is quite small, so I'm a bit confused as to why you're
having them toil away doing work that isn't very efficient. About 95%
of the time I personally spent speccing things out did not help me in
any way gain perspective on the features I was asking for. Asking for
a good pros and cons analysis, rewriting existing sources to the
proposed new feature to see what it would look like 'in real
life' (something a JLS spec is no good at, I might add), and doing a
simple analysis that its likely the current parser architecture (LL
[1]) of javac can be retrofitted rather simply are all simpler to do
compared to writing a full spec+prototype, and yet they would have
helped much, much more in getting a feel for the cost vs. value
relationship of a feature. Also, whatever introspection is gained
solely by working on a JLS patch and a prototype can still be used to
cancel a project, which is why rule #2 is in there.

On Sep 15, 3:53 am, jddarcy <jdda...@gmail.com> wrote:
> On Sep 13, 7:16 am, Reinier Zwitserloot <reini...@gmail.com> wrote:
> [snip]
>
> > Where I take exception, is when Joe Darcy
> > complains about lack of community input.
>
> Oh, there is lots of externally community input ("I want feature X
> now!", for many values of X); there is much less external community
> contribution toward achieving those features.
>
> > I call truth distortion: Of
> > course there's no community input. You killed it. Communities don't
> > just magically show up on your doorstep. They grow. And to grow, you
> > need to nurture them.
>
> Agreed.  The blog posts I wrote toward the end of 2008 before the
> Project Coin call for proposals period were intended to nurture in
> others the design context we've been using to evolve the language.
> Also, a light hand was taken in managing traffic on the coin list to
> not scare away those wavering on approaching the doorstep.
>
> -Joe
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The 
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to 
javaposse+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to