On first interactions with open source communities…

[bzar]

I think it is safe to assume that as an open source project, striving to grow our community, we should make first interactions of new contributors with us a pleasant one.


So when commenting on a new contribution or attempt, we should try to either say something positive or don’t say anything.

• If the contribution is not useful then sugar coat you criticism. Because while the contribution might be bad, the person who did the contribution showed initiative to help out. We need to harvest this momentum and help integrate the person into the community.
  
• If the contribution is useful then praise the developer. Making him feel useful. I learned from Lydia Pintscher to not only praise good contributors, but grant them autonomy to play around. This would allow them to master their craft, which will lead to them feeling like they have a purpose to stay.
  

What do you think?

http://seilo.geekyog...ce-communities/


What do you think? I agree.

 

[mcobit]

Agreed

 

[foxblock]

I agree to some extend, I never sugar coat my criticism though. I will always point out if I think something sucks (and be quite direct about it), but I try to be fair and highlight good as well as bad parts and go into details.


At the end of the day you only learn from being criticised, but it should be fair and extensive, not just an easy "this sucks!" (this does not help anyone, dickhead), one should go into why something sucks and how to make it better, not just point it out.


I fully agree on the second part though, there are only a few people actually showing acknowledgement and praise if they like something, so usually all you get is critique and bug reports, which can be quite discouraging.


Or you get nothing at all, which is even worse.

 

[Prometheus]

Absolutely agreed with both the quote in the opening post, and with what foxblock said (though, I'm not entirely sure if they really mean "sugar coat it" in the original quote, or just "give constructive criticism"* - the latter is how I took it, at any rate, since that's how that wording came off, to me).


*(There's plenty more that I could say about this, but it would lead to a somewhat off-topic rant, so I'll spare you all. )


But this doesn't just apply to open source communities - it applies to anything. It's just basic good manners.

 

[Mr Rob]

Somewhat related to communities, the Free Sound Project recently released a paper discussing a lot of the characteristics of their community. It may be an interesting read....http://mtg.upf.edu/node/2479

 

[bzar]

I understood the sugar coating as going easy on the new guy. Instead of burying him in (even valid) critique might just scare him away or demotivate him. Don't tell every little thing that bugs you at once if the receiver is not used to it. Give something small to improve, then praise on success. Rinse and repeat. Positive reinforcement makes for a happy and motivated developer . When the developer is more at home in the community and used to dealing with different types of criticism, then you can start pouring your comments in all at once.

 

[mcobit]

Some person from irc comes to mind, who would just say: Who gives a crap

 

[craigix]

I agree with this.

 

[WizardStan]

Sugar coating criticism would simply be something like: "It's obvious you worked really hard on this and we appreciate the effort, but we can't use your patch because ..." rather than the more direct "This is terrible". It simply means making the person feel like their efforts are appreciated even if the effort is ultimately wasted. When you meet someone that does put forth effort and only fails at understanding the project or perhaps some basics of the style, these people can be moulded to become productive members, eventually adding value to the project if they can be convinced to stick around.


On the other hand, I have worked with people in a professional capacity that actually subtracted value, made everything worse simply by existing. These people need all the encouragement to GTFO they can get.

 

[craigix]

One of the criticisms which I find the most absurd is when a game/app is popular, being worked on at a steady rate, and some pedant will come in and start to tear apart the persons coding style and tell him how it's all 'wrong'.


I'm a firm believer if it works, is fast and does not leak memory then it's good - however it's coded.

 

[Pickle]

I think in general the developer needs to have some sort of backbone in order to properly handle feedback and not take things personally. Of course the reviewer should use common manners.

One of the criticisms which I find the most absurd is when a game/app is popular, being worked on at a steady rate, and some pedant will come in and start to tear apart the persons coding style and tell him how it's all 'wrong'.


I'm a firm believer if it works, is fast and does not leak memory then it's good - however it's coded.

Using coding standards is a very useful skill to work on. You can avoid bugs and it makes your code readable. Having seen some of your code from the past you have some very bad habits (should i have sugar coated this criticism? ) Your code works, but it pain to understand. Could you go back and recall what you meant to do with any given piece of code?


One example:

if A if B if C

But some things can be useless. Like one rule I was into a one point thought that each class should have a getter/setter for each variable in the class. You can see this in the pirates code base. I later came to conclusion this just adds bloat and a lot of time wasted making the getter and setters. I know how im using the variables so what protection am i really adding.


Another example is using points made by the book Effective C++. Which gcc has some built in checks for. Of course you dont need to follow them in order to get something to function. But in one rule its expected that each member of the class is initialized in the constructor, Ive had issues where code actually executed incorrectly because i had not init the variable.


Another example, dont use unaligned casts like value = *(int *)ptr_data. This while functionally correct on most devices, would give erronous results on archs that wouldnt support such accesses. The GP2X, Wiz, Caanoo are such devices. By avoiding this technique your code can be more portable.

 

[bzar]

Like one rule I was into a one point thought that each class should have a getter/setter for each variable in the class. You can see this in the pirates code base. I later came to conclusion this just adds bloat and a lot of time wasted making the getter and setters. I know how im using the variables so what protection am i really adding.

Going a bit off on a tangent I see this more as a consistent way of creating a property abstraction. Some of your properties may be "virtual" (they are actually just a facade for some state that exists elsewhere that your objects just manage) and some might require special handling for example for their setters the user does not need to worry about (freeing dynamically allocated memory, freeing I/O resources and stuff). By doing setters and getters for all properties you expose a consistent interface to your properties instead of having some with accessor/mutator methods and others publicly visible. It's easier on the developer using your code to get a grasp on, even if it's obvious for you. Of course if you only read your code, all this is of course moot . In addition with inline trivial getters/setters the bloat stays in the code base and won't (AFAIK) affect the resources used during execution.


More and more modern languages include a property system that you can customize setters and getters for as needed and they're executed automatically during member access and assigning to them. This of course takes away both issues.


EDIT: I decide whether to use public members or accessor/mutator functions on a class by class basis, but always only one or the other per class.

 

[Miner49er]

I fully agree not to be harsh on someone who is new to a community _and_ is actually offering something - that just going to scare someone off. Also, you don't know how old the person is; they might be a little kid and I would hate the thought of a bunch of adults described something my son had done as "sucky". However, it is very important to always give constructive criticism.


Interesting point about coding-standards. I am a VERY FIRM believer in coding-standards. I've worked in places where there were no standards in place and maybe I'm just a shit coder but I find working with code like that I total nightmare. It angers me to be honest. In the context of little games for things like the Pandora or 'apps' for mobile phones where only one person is working on it though, it's up to the programmer - if they want a headache when it comes to looking at it again in a few months, it's their bag! Myself, I like to make code readable (again, I could just be a shit coder or perhaps I have a useless memory but without reasonable naming conventions and comments, I have to re-learn my own code).


re: getters/setters. I like 'em personally but I do agree that they can end up adding loads of pointless bloat...and also a little CPU overhead I guess. It's just useful if you find you need 'do something every time the variable is accessed' later down the line.


I do enjoy programming...

 

[vadsamoht]

I agree with the article and WizardStan's comment with the caveat that making the user's contribution feel worthwhile should never come before letting them know exactly where they went wrong (assuming the problem is not a very minor one), though of course the two are almost never mutually exclusive. Especially if the user is either new to programming or contributing to projects of the type in question few things are worse than knowing that you've messed up but having no idea how to rectify the situation. Naturally, this applies less to the more experienced and proven developers, because they obviously know what they're doing to a greater extent.

 

[ibisum]

I agree with this position, but I think its a difficult thing to manage in newly-formed teams that don't, intrinsically, have an overt decision to work directly with each other. Its sometimes hard to get code from a stranger when you have had all the ideas about something already, and then realize your ideas were wrong - its also hard to have to explain things to every newcomer and then put up with their tantrums, too, on the flipside. There is a successful big region in between the extremes, though, and generally I welcome any effort to reduce extremities when dealing with others. I've had some involvement in some F/OSS projects lately where there could definitely be more said about what is being said and how its being said, but in the same breath one must admit that working code is what counts.