On Sat, Oct 5, 2013 at 7:03 AM, Benedikt Ritter <benerit...@gmail.com> wrote: > > I'm not sure I agree with all of your points. Yes, the sandbox is a place to > try new ideas out. Does this mean certain quality criterions do not apply? I > don't think so. This all has to be corrected before promotion, so why not > make it correct right from the start? >
Sometimes it helps people to get their ideas down and working without worrying about "correctness." That's why writers have a rough draft, after all. The creative process is best left unencumbered when nurturing a new idea. The sandbox is all about letting folks work on an idea they have. It's a *sandbox*! Yes, it does mean that certain quality criteria do not apply, until the point when the component wishes to graduate to "proper." At that point, we can put on our white gloves and go over every last line (or look at Sonar reports) if we wish. > Is pointing out that something may be improved nit-picking? Well, I think it > depends :-) Just sending a -1 for a commit like this would definitely be. In > this case an improvement has been pointed out. I'm more then happy for > feedback like this, because it helps me become a better developer. And in the > end, discussing commits is part of the game ;-) > Yes, in a sandbox environment, pointing out a small "magic string" infraction is nit-picking. Leave the authors alone and let them work through their ideas. If you want to help out with the code, jump in and help. It takes longer to write an email and participate in the back-and-forth that ensues than it does to just fix it yourself. For issues like this, we really need to be using a tool like Sonar. Sonar will objectively look at the code for infractions such as this (among many others). The author can then look at the Sonar reports and see areas that might need improvement at their leisure (the group will also do so before graduating the component to proper). The other great thing about Sonar is that it has verbiage in there about why the rule is a rule and what can be done to fix the issue, so it's also a teaching tool. Most likely, the author fully understands why it's bad to have "magic strings" in their code, but just wanted to get their ideas into code and working before worrying about such issues. They can clean it up later (or some of us can jump in and help). This is the exact reason that I personally would *never* start a new project here at Commons again. I would invite certain colleagues to collaborate on github or something and then later bring the code into the organization. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
