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.
--
_______________________________________________
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
