Very well done. Presents a balanced view.
Thanks,
Nicky
>________________________________
> From: Boroondas Gupte <slli...@boroon.dasgupta.ch>
>To: opensource-dev@lists.secondlife.com
>Sent: Friday, April 26, 2013 3:48 PM
>Subject: [opensource-dev] How to ask the right questions; how to support
>newcomers (was: <rant> lack of respectful communications on opensl and other
>viewer irc channels)
>
>
>
>On 26.04.2013 01:48, Nicky Perian wrote:
>
>From what I have read about open source projects flaming newbies is the norm.
I surely hope that's not the case in general nor in the Second Life Viewer
community.
>
>
>Let's get real folks, it is not necessary to continually flame someone asking
>for help. I think that is why there is so little traffic on #opensl. Why ask
>when your direct question will go to your motive for asking such a question in
>the first place.
Inquiring people, especially those unexperienced in topic, why they asking a
specific question is often beneficial: If the more experienced know your goals,
they have a chance to figure out whether you're asking the right question to
accomplish it. A correct answer to the "wrong" question might only lead the
newcomer further down a dead end street.
>
>There's no disgrace in asking the wrong questions. While some
(lengthy) rules of thumb can help one avoiding the worst mistakes, any more
involved topic requires some preliminary knowledge and experience to even be
able to ask the questions that should be asked for accomplishing a goal. While
some of that knowledge is available from documentation, a lot of it can only be
gained by collaborating and asking questions, even the "wrong" ones.
>
>So there is no reason to be offended just because someone's
questioning your questions. (Unless, off course, when they are rude
and bullying you about it, which obviously would be unhelpful and
uncalled for.)
>
>
>For instance you shouldn't be in that part of the code as you don't have
>enough experience. I ask, why not? The viewers we help provide are for users
>enjoyment of a role play game. There are not being deployed into an industrial
>plant control system with triple redundant code and hardware.
Sometimes, it is prudent to avoid parts of a program as a beginner, because
they are written in such a bad style that it might spoil yours or because they
are so fragile that merely looking at the code will break it.</hyperbole> On
the other hand, a great way to learn what anti-patterns to avoid, is to get
your hands dirty while dealing with the problems they create. So be critical
when reading code. Just because it works doesn't mean it's how it should be
done or that you should adopt its quirks.
>
>Some developers might be afraid that newcomers inadvertently litter
and vandalize their code. With a working review process such fear
should be unfounded. However, it can be frustrating for all to have
to completely reject a major amount of work under review because
it's beyond repair or taking the wrong approach altogether. Thus,
it's important to guide newcomers' experimentation, without
restricting it too much. Maintaining that balance isn't easy and
supporting someone can be a lot of work, so I can understand if some
would like to evite it and would rather have newcomers spend their
time on something "easier". Shooing them away from the code, though,
isn't the right answer.
>
>So you're right, when you write:
>
>To get experience digging into the unfamiliar and trying to figure things out
>is a necessary step. At times it is nice to be able to ask more experienced
>programmers for advice. If given freely and correctly that can only help the
>whole viewer developer community.
>
>One developer recently said he deliberately gave wrong information so that the
>person would spend a couple of days sorting out what was wrong. Is that
>helping our community of developers in any way?
No, it isn't. While it's a good idea to challenge learners (if they have time
to deal with the challenge and you have time to support them through it), so
that they gain deeper understanding than when spoon-fed the answers, it's fully
sufficient to provide them with just enough hints and support to figure things
out by themselves. Actively misguiding them helps no one and should be
disdained.
>
>Cheers,
>B.
>
>_______________________________________________
>Policies and (un)subscribe information available here:
>http://wiki.secondlife.com/wiki/OpenSource-Dev
>Please read the policies before posting to keep unmoderated posting privileges
>
>_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges
