Re: Communications in Projects...

[Drazen Kacar <dave arsdigita com>]

Jim Gettys wrote:
> I promised to draft this last summer: I did, but did not see a good
> opportunity to send it when people were listening

Wise.

> 	o if development of key technology is mostly done in a small
> 	teams, particularly when commercially supported, much paranoia can
> 	be avoided by good communications of plans, enhancements
> 	and changes (particularly incompatible ones that affect other 
> 	projects).  Recommendation: do all your development on open
> 	mailing lists, reserving a infrequently used list for proprietary,
> 	commercial discussions.  If you already have heavily used internal
> 	only mailing lists, habits die hard, so turn them off and reestablish
> 	public lists to force this separation, or your developers won't
> 	bother to switch.

I have a small addition here.

I think it would be good to recognize the fact that in reality all
development won't happen on public mailing lists. The reason is simple:
human communication takes time and it's much faster to talk with a small
group face to face than to discuss things on the mailing lists.

It saves time, you can draw little circles on the flip charts, you can
discuss things in a pub or some other place where you feel comfortable,
you can steal some time from your local expert who works on a completely
unrelated project etc.

So if we have small corporate backed teams, the probability of them
working at the same physical location is rather high. In that case
they'll tend to discuss things face to face, because it's more efficient.
This usually happens early, with the design decisions. There's nothing
wrong with that as the initial design strategy, I think.

However, from the outside it might appear as the corporate conspiracy
because the design decisions were apparently made by the small team which
didn't communicate enough.

Another possible problem is that the small group, even if enhanced with
the local experts who work on unrelated projects, might not be
technically as good as the larger Gnome population.

Therefore, I would suggest the following: after your co-workers have
mutilated half of your grand ideas while not attempting to make a
complete idiot of yourself, write down what remained and send that to the
mailing list. If the team was good enough and the ideas were technically
sound, mailing-list discussion won't take too long and it will tend to
avoid noise. Small bits and pieces that somebody else can fill in could
save a lot of trouble later. And if somebody manages to find a large
problem with your design, it's even more important to know about it as
early as possible.

-- 
 .-.   .-.    Unlike good wine, bullshit doesn't improve with age.
(_  \ /  _)                                                    -- John McLean
     |        dave willfork com
     |