On Tuesday 28 August 2007 15:40, Andrew Sullivan wrote:
> On Tue, Aug 28, 2007 at 02:44:26PM -0400, Robert Bernier wrote:
> >
> > This sounds like basing a decision on getting the most benefit with
> > the least amount of work.
>
> I am unaware of a better mechanism by which one decides which work to
> do. The important thing is what "most benefit" means; and that turns
> out to be hard to unpack.
Many companies and govt agencies work only hard enough that they can say
something was accomplished. It speaks of environment that is bereft of
resources and must make do with what they have i.e. they lack investment
resourcess
>
> > I respectfully counter your argument by suggesting that in this
> > matter the effort, although significant, is justified by the
> > benefits.
>
> So what are they?
Community participation. Constructive debate makes for a community with a more
people skilled membership.
The name change question is worthy of a discussion ... an administrative
discussion... with pros and cons in the context of becoming better known in
the world, And then a decision is made. For the record; although I believe in
the name change I still have yet to learn the full cost. I don't think
anybody does for that matter. We need to sit down and calculate the manhours
and the required skillset.
Don't underestimate language: No disrespect but I find that unilingual
speakers lack the perspective to appreciate the needs of those outside their
culture. I remind you that the largest and most vibrant segment of the
PostgreSQL community doesn't even speak English (sic Japan).
> > I argue that the exercise of debating and, if it comes to pass,
> > implementation has benefits that far outweighs the effort.
>
> How do you know that?
It's an axiom that practice makes perfect. Debating sharpens people's skills
in identifying the real decision making issues.
> So far, I have seen no serious discussion of
> what the costs of a name change might be, or what the benefits could
> be were we to adopt something else.
I agree. A definite number crunching exercise.
Successful projects typically run in cycles of three.
One example of taking a big investment risk is General Motors. They went
through three failed design teams before they found one that agreed with
senior management that it was possible to make aluminum engines and then did
it.
Another car example is the policy that the Japanese car mfg followed by hiring
graduate engineers to assume the positions that union blue collar workers
were doing in North America. They believed that there was more profit in
valuing quality than what the big American car mfg were (and I remember when
the big five laughed at the Japanese approach too).
> There _will_ be confusion, work
> for package maintainers, nasty upgrade problems...
yup. lots of work but still worth the effort of asking the question
