Re: [opensource-dev] lack of respectful communications on opensl and other viewer irc channels

[glen]

On Thu, 2013-04-25 at 16:48 -0700, Nicky Perian wrote:
> From what I have read about open source projects flaming newbies is
> the norm. 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. 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. 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? Please lets do
> away with Nazi persecution of those with less knowledge. Granted,
> there are no night stick bearing thugs breaking knees. It is much more
> insidious than that. In my opinion, putting someone down outwardly
> usually comes from a person who is inwardly very insecure.
>  
> Nicky  
> ___
> 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

Agreed. It is not ok to place artificial barriers in the way of
learning. It is counter-productive in the extreme and /never/ has the
result intended. Someone new to the process needs to meet with success
and encouragement early on rather than snickering and failure if they
are to become productive members of a community.

I've been a lurker here for nearly three years and haven't contributed
anything since I fixed an X/ATI memory bug that a Linden completely
rewrote anyway before release, but I've still been watching. I haven't
seen a huge amount of this here, though it has happened. But this used
to be a hopping group; it's petered out to terse Q/A with very little
discussion. It seems that all discussion happens at the inworld meetings
that not everyone can attend and I believe that's just as bad as it's
still a barrier to participation.

--GC


___
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

Re: [opensource-dev] lack of respectful communications on opensl and other viewer irc channels

[Robert Martin]

On Fri, Apr 26, 2013 at 11:28 AM, glen  wrote:

> It seems that all discussion happens at the inworld meetings
> that not everyone can attend and I believe that's just as bad as it's
> still a barrier to participation.
>

or worse meetings that are being held 98% in VOICE (and of course no
recording is being made). Personally i think that any Linden giving a RTFM
or FOAD answer to a question should be a FORMER Linden (esp when TFM has
not been written yet).


-- 
Robert L Martin
___
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

[opensource-dev] How to ask the right questions; how to support newcomers (was: lack of respectful communications on opensl and other viewer irc channels)

[Boroondas Gupte]

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. 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

Re: [opensource-dev] How to ask the right questions; how to support newcomers (was: lack of respectful communications on opensl and other viewer irc channels)

[Nicky Perian]

Very well done. Presents a balanced view.
Thanks,
Nicky






>
> From: Boroondas Gupte 
>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:  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. 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