[Lazarus] Project management

[Martin]

On 01/03/2012 14:54, Hans-Peter Diettrich wrote:
> 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.
Of course. Both ways have pro and  con, both have advantages and 
disadvantages. And I thought, that I had made that clear, in what I wrote.

Each developer, contributor or other person, has a certain amount of 
time. This time gets invested. As with any investment one has to make a 
decision. based on philosophy and knowledge and other factors. (The same 
knowledge still leads to different results, depending on the philosophy 
followed.

>
>> "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.
Well if certain questions are ask often enough, so they create more work 
to be answered, than documented, then they probably will be documented....

Yes I see, for the new-comer, this is less attractive. But it should be 
possible to see that for those who answer-or-document this is easier. 
(As they can choose the cheaper way).
The previous given answers are not lost. They can be copy and pasted 
into the future doc.
They can also be found in the mailing list archives.

So again it is philosophy. Is the potential newcommer, who will read a 
small selection of the (assumed complete) docs, worth the work of 
writing this doc (including the parts that will never be read (even if 
only because the got replaced due to updates/changes/refactor..., before 
any one needed them)?

I acknowledge the "nice to have", but I do not think "at all cost".

>
>> 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 :-(
I consider this a sarcasm gone badly wrong.

If those kind of implementation exist (rather than just being perceived 
as such by individuals), then for those there are many reasons possible. 
Many of which would still apply, even if ass the docs existed.
What makes you thing out of all those reasons, it must be the missing docs?

>
>> 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.
Yep you are describing a philosophy here. One of many possible.