I do not claim to a be brilliant Perl programmer, but I try and I'm always will to listen to constructive criticism and alternate viewpoints. I try and do my part by releasing as much of my work into the public domain to give back to the community something I hope is useful in creating systems. It's more then most do and, while I don't expect any accolades or even a pat on the back, I do expect some degree of consideration and etiquette so I don't regret my decision.
Tommy boy here demonstrates how you don't do that and loose the ear and respect of a developer with a post here to in the CPAN reviews section. (Kind of funny that this post comes from someone who can't get their own modules to test properly.) I replied:
Saw your comment in the CPAN reviews section and it was really inappropriate. If you have some suggestions for improving the module then I welcome your constructive criticism. However I have no time and respect for the opinion of those who flame my (free nonetheless) work in an open forum rather then addressing it with me personally or as a bug report via rt.cpan.org.
So here is a bit of advice for those of you using other's code – especially free of charge – to avoid situations like these.
- There is no need to be angry, snippy or snarky – be constructive in your criticism instead. Developers releasing their code to the public, particularly the open source kind, are good people by the nature that they'd give their work away to complete and virtually anonymous strangers.
- Address bugs with the developers or through some bug tracking system were they will be seen and handled. Spewing to a mailing list or public forum without giving a developer the benefit of the doubt is pointless to resolving the issue and contributes nothing to the community at large. It also burns bridges if the developer catches you.
- Don't take not getting your way personally. Fixing bugs is one thing. Suggesting features or changing the way things are done is another. I've been other side of making suggestions and even submitting patches to modules to get passed over. I've probably had as many graciously accepted too. While completely ignoring opinions and requests of others is a bad idea, ultimately it is their vision, time and effort to manage. Development in a public arena is a balancing act – options differ and sometimes come into direct conflict with each other. It comes down to the developer to decide where to take their time, effort and work and unfortunately that may not be where you had personally hoped.
<p>I do not claim to a be brilliant Perl programmer, but I try and I'm always will to listen to constructive criticism and alternate viewpoints. I try and do my part by releasing as much of my work into the public domain to give back to the community something I hope is useful in creating systems. It's more then most do and, while I don't expect any accolades or even a pat on the back, I do expect some degree of consideration and etiquette so I don't regret my decision.</p>
<p><a href="http://search.cpan.org/~tommy/">Tommy boy here</a> demonstrates how you <strong>don't</strong> do that and loose the ear and respect of a developer with <a href="http://cpanratings.perl.org/d/XML-RAI">a post here</a> to in the CPAN reviews section. (Kind of funny that this post comes from someone who <a href="http://testers.cpan.org/show/File-Util.html#File-Util-3.14_7">can't get their own modules to test properly</a>.) I replied:</p>
<blockquote>
<p>Saw your comment in the CPAN reviews section and it was really inappropriate. If you have some suggestions for improving the module then I welcome your constructive criticism. However I have no time and respect for the opinion of those who flame my (free nonetheless) work in an open forum rather then addressing it with me personally or as a bug report via <a href="http://rt.cpan.org/">rt.cpan.org</a>.</p>
</blockquote>
<p>So here is a bit of advice for those of you using other's code – especially free of charge – to avoid situations like these.</p>
<ul>
<li><strong>There is no need to be angry, snippy or snarky – be constructive in your criticism instead.</strong> Developers releasing their code to the public, particularly the open source kind, are good people by the nature that they'd give their work away to complete and virtually anonymous strangers.</li>
</ul>
<ul>
<li><strong>Address bugs with the developers or through some bug tracking system were they will be seen and handled.</strong> Spewing to a mailing list or public forum without giving a developer the benefit of the doubt is pointless to resolving the issue and contributes nothing to the community at large. It also burns bridges if the developer catches you.</li>
</ul>
<ul>
<li><strong>Don't take not getting your way personally.</strong> Fixing bugs is one thing. Suggesting features or changing the way things are done is another. I've been other side of making suggestions and even submitting patches to modules to get passed over. I've probably had as many graciously accepted too. While completely ignoring opinions and requests of others is a bad idea, ultimately it is their vision, time and effort to manage. Development in a public arena is a balancing act – options differ and sometimes come into direct conflict with each other. It comes down to the developer to decide where to take their time, effort and work and unfortunately that may not be where you had personally hoped.</li>
</ul>
