[Lazarus] Project management

[Hans-Peter Diettrich]

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