Very interesting video I’ve been looking at for the last 10 minutes, still a lot more to watch. Thx dfighter for sharing it
“How to Protect Your Open Source Project From Poisonous People”
I recommend everyone that cares slightly for TC to watch this video /emoticons/default_smile.png
A really interesting video, and it seems that the big lesson here was one: write things.
The sad thing is, the people who really need to take notice of this, don’t realize they are the poisonous people, especially if they are the ones making a lot of commits, thinking that is all it takes to be a good contributor… Pay close attention to needing goals, and limiting the scope, which does not mean “everyone do whatever they want, willy nilly”
22:34 I have been saying a lot of this for years, especially at this point.
It’s interesting that you say that, Paradox. When they were talking about “Identifying Poisonous People” you actually meet all most of the requirements. Congratulations.
That’s exactly what is wrong with this project is that you guys think I’m the poisonous one.
You’re not alone paradox.
You do say some right things, no doubt in that, but the shit we have to take from you is not worth it, Paradox.
It’s funny how you already started to “fight” over who is poisonous. http://www.freesmileys.org/smileys/smiley-basic/popcorn.gif
Thanks for posting this. I had bookmarked it a while ago but lost my bookmarks to a corrupt Firefox profile.
Politeness
Respect
Trust
Humility
/emoticons/default_smile.png
http://blog.codinghorror.com/what-if-we-could-weaponize-empathy/
Another interesting article on the topic of online communities
“14 Ways to Contribute to Open Source without Being a Programming Genius or a Rock Star”
for all the community members who are not top skilled developers and still want to help the project but don’t know where to start /emoticons/default_smile.png
http://henrikwarne.com/2015/04/16/lessons-learned-in-software-development/ “Lessons Learned in Software Development”
Livecoding.tv is a livestreaming platform where people code products, live.
We connect people around the programming languages that they love.
Livestream notifications
https://www.javacodegeeks.com/2015/07/a-few-valid-reasons-to-reject-a-bug-fix.html
Bug fixes are [I]not features[/I]; they must be small and focused. It’s a very typical mistake for programmers to get carried away while fixing a bug and introduce some refactoring together with a fix. The result is that the patch gets rather big and difficult to understand. I’m not against refactoring; it’s a very important and positive thing for a project, but do it separately [I]after [/I]the bug is fixed and merged.
No refactoring while fixing a bug!
[FONT= Tahoma]Always fix one issue at a time — simple as that. No exceptions.[/FONT]
Combining several bug fixes into a single pull request is a very bad practice. No matter how simple the fix is, keep it separate from others.
http://www.codeproject.com/Articles/783574/Five-Phases-of-Developer-Maturity “Five Phases of Developer Maturity”
https://medium.com/swlh/code-reviews-can-make-or-break-your-team-a3cfdcc15de1
Code Reviews Can Make or Break Your Team
Man… I lost an hours to this thread and the tangents of just the other night…
http://www.javacodegeeks.com/2015/07/a-few-valid-reasons-to-reject-a-bug-fix.htm
^ dead link.