Fyi doc is here http://commons.apache.org/sandbox/commons-monitoring/configuration.html Le 5 oct. 2013 14:30, "James Carman" <jcar...@carmanconsulting.com> a écrit :
> 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 > >
