Reading this thread, and the threads just like this which pop every
six months or so, What is clear is that :
1) When new documentation is announced it is appreciated, but...
2) Very shortly after users come forward and decry how unsufficient
the documentation we have... this
takes typically two or three post... Its seems that actually
announcing documentation seems to provide
an excuse to vent ones frustration.
3) Software engineering and frustration often go hand in hand, its
part of the life, software engineering is hard
and how hard is often mis-understood by those setting deadlines,
all too often engineers end up with too little
time and too much to do.
Over the years this really hasn't changed much, we as software
engineers can achieve more with less time
thanks to all this lovely technology, much of it open source, or
much lower cost and faster hardware, but
expectations have moved with this increased capabilities.
4) When people are frustrated and overworked they tend to bark
louder, they might have a just cause, but
perhaps write in ways that are less congenial than they would
when less stressed. They can also be a bit
less understanding of others and appreciative of the effort of
others. I know this to be the because this
happens to me, I can be one of the bears in the picnic garden.
To this I'd like to turn around of reflect on
items 1 followed shortly after item 2. What this conduct is effectively:
Person A gives a gift to everyone, giving the time and expertise.
Person B says "thanks, but frankly it's not good enough, what
you've done is next to useless to me."
Now to me... Person B is not being too polite, and certainly not
encouraging in any positive way.
5) Venting of frustrations can be contagious, if one person starts
being dispropritionatly demanding, then others
often get carried into, it would seem to become fair game -
sometimes a game of manipulation can arise,
not in this thread, but it has happened very occasionally in the
past, but these types of threads are the
type of ones that can lead in this direction. I think this type
of conduct is in part motivated by frustration at
not being able to dictate the priorities and work of others.
6) In an open source world the health of a community and it's
ecosystem is one that grows strong from shared
needs, sharing of expertise, and giving of time and goodwill.
The ecosystem is very fluid, in some ways fragile, but
in others ways surprisingly robust.
What I have learnt that is little one can do to dictate to
others, not even as project lead do I have this power, I
only have real control over my own priorities and work schedules,
and that what gets checked into the official
SVN trunk and releases. One can request for assistance on
different tasks, and if someone steps up this is
awesome and something really appreciated and cherished, but you
have to accept what help comes from
goodwill, or shared need. Its important to realise that one
can't demand things, it simply doesn't work, even
for the one who is supposed to be project lead... to have a
successful open source ecosystem one has to
roll with fluid nature of the community, try to make best of
opportunities that arise.
7) Given the context of 6, one simply can't go click ones fingers and
expect to things to happen, in fact its
counter productive - its harms the community and undermines your
ability to achieve your own goals.
It might feel good initially to vent your frustration, but isn't
healthy or productive.
8) Now maintaining a healthy ecosystem requires one to recognize
weaknesses and failures and then fixing
them, in the case of bugs its might be hard technically to hunt
down and fix a bug but overall is actually
something that such a community is relatively well geared up
for. There are other things like documentation
that might be less technically challenging, but logistically are
much harder to create the right conditions
that things can happen spontaneously.
Curiously the easy things that this community does well is things
down out of things one can justify out of
self centered motivations i.e. I have a bug, I need it fixed,
I've found a fix, its much easier for me if I get this
fix in SVN and the next version of the OSG so here it is, please
integrate it. The same applies to much of
the feature development that goes into the OSG, the motivation of
the feature development is to help ones
own project, and it just so happens that giving this work away is
pretty inexpensive time wise for you, and
you get back benefits from other adding to it/fixing
it/maintaining. All things that are justifiable from a
selfish point of view.
Things like documentation and osg-users support are different,
its much more out of kindness and wish
to help fellow engineers. osg-users support is actually
relatively light weight form of giving - its relative
quick to fire off an email to help someone out, and the human
engagement itself is pleasurable, because
are all social animals. Documentation is really out there on the
selflessness spectrum, it takes a great
deal of time and effort, its not a light weight social activity
that one can give easily, and the rewards for
this effort are not great in social or economic terms. Surely
its this effort that truly deserves the
greatest appreciation.
9) Yeahh but... I agree with all that.. but MY point is...
Heard that before :-)
Human nature sometimes can't get the better of itself, it can't
hold itself back, even when its not the
effective thing to do.
10) So.. advice, if you have an issue you want to raise then do so,
but do so in a positive and sensitive way.
And absolutely don't go hijacking other threads to vent your
frustration, use a new thread if you have
something important to say. Please remember the fluid nature of
the ecosystem, if we want something
to change for the better we have to sow the seeds and nurture
them, barking "grow, grow dam you" at
baron soil won't ever get you anywhere.
11) This thread should have been entirely about the RefManual 2.2 and
the positive value it has to the community.
So I'd like to conclude and say a big thank you to Paul Martz for his
effort on the Ref Manual 2.2.
Robert.
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
