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 <http://www.catb.org/esr/faqs/smart-questions.html#goal> 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 <http://www.catb.org/esr/faqs/smart-questions.html> 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
