Oops, meant to comment on this piece of the process: > > 3. enforce conformance by asking the author to make revisions to > > non-conforming commits rather than changing their code for them > > In your item 3. I have been trying to avoid this kind of > pointing finger because when I attempted it, the result was > not satisfying. Instead I have set up systems to check things > automatically hoping that everyone would pursue this. Because > the number of checkstyle warnings have increased, one could > argue that I have failed also in this. We need someone with > better socials skills than I have to do the "asking".
Did everyone commit to following the process you put in place? Is this the most important thing that needs fixing to make ArgoUML a success? The answers to those questions would influence what is the best approach going forward. Having one person going around cleaning up after everyone else is an untenable approach in general and in this specific case, because it's the project leader, it's taking effort away from planning and other critical leadership tasks. >From a tools point of view, improvements which would encourage better behavior include: 1) personal stats instead of group stats, 2) email or other notification when a developer's commit caused counts to increase or exceed some threshold, 3) tracking stats over time so trends can be identified, ... probably lots of other stuff. Let's take a step back though and look at what we're trying to achieve. Are we trying to drive some number to zero or are we trying to improve the quality of the code base or are we trying to improve the quality of the functionality delivered to the user? They're related to a greater or less degree, but we shouldn't lose sight of the end goal -- the user experience. Focusing solely on the metric results in comments like: /** * @return the result */ which improves the metric without improving the code at all, but a single-minded focus on this has bigger impacts. A recent commit consisted of completely cloning a method and then commenting out a few lines leaving two methods which are 90% duplicates. When the style review was done, all the indentation, wrapping, and punctuation was cleaned up without addressing the biggest code quality problem -- the cloned methods. That's not an effective use of resources. Tom --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
