Martin schrieb:
On 01/03/2012 00:35, Hans-Peter Diettrich wrote:
Juha Manninen schrieb:
So, what does the management mean in practice? Should Lazarus be
managed differently from how it is managed now?
IMO it's not so much a matter of management, but of mind shift. The
developers should share more of their knowledge, apart from only
writing code. Until then every management attempt will be ineffective.
BTW this is not a criticism on Lazarus only, I found that attitude in
many open source projects, and small (one-man) companies. Failure to
educate co-workers is usually justified by a lack of time ("busy with
more important things"), and results in never decreasing work load.
Well but it is a question of philosophy then, isn't it?
In either case the answer has very *practical* consequences.
"provide what is required (answer questions)" versus "provide all (or
some/lots) upfront"
You assume that all questions *have* to be asked. But with insufficient
upfront information it can require many questions (and answers), until
the discussion reaches the *essential* points.
It does still cost time to write up all the info, and guarantees
nothing. While if someone wants to do work on something, there are much
better chances that the work (providing infos/answers) will bear fruits.
This finally explains the often confuse and inconsistent
implementations, found across the entire LCL :-(
And should the person who could answer become unavailable, then yes
indeed documentation would help (until outdated, as the sack of a
maintainer would lead to this)
Just to prevent such an unwanted situation, the initial documentation
should accompany the implementation, or follow it immediately. Consider
the way how patches have to be acknowledged first, before they become
part of the code base. The same principle could be applied to all *new*
work on the code base, except bug fixes.
In my experience it's helpful *also* to the implementors, when they have
to write a few lines about the purpose or intended used of their work.
What cannot be explained in a few words is almost a bad or inconsistent
implementation, that better should be changed before committing.
DoDi
--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus