Hi *, and others (real people included), The project's representations in SonarCloud.io (as a free service via the ASF) gives us up-to-date information on a variety of issues related to the various types of code (java, groovy, js, xml, etc.), like:
- bugs - security hotspots - code smells - duplicate blocks See https://sonarcloud.io/dashboard?id=apache_ofbiz-framework and https://sonarcloud.io/dashboard?id=apache_ofbiz-plugins. With a PullRequest submitted to the Github repository we see in comments thereon how the commits are assessed. See e.g. https://github.com/apache/ofbiz-framework/pull/14 Best regards, Pierre Smits *Proud* *contributor* (but without privileges)* of* Apache OFBiz <https://ofbiz.apache.org/>, since 2008 *Apache Trafodion <https://trafodion.apache.org>, Vice President* *Apache Directory <https://directory.apache.org>, PMC Member* Apache Incubator <https://incubator.apache.org>, committer Apache Steve <https://steve.apache.org>, committer On Thu, Feb 13, 2020 at 6:04 PM Michael Brohl <[email protected]> wrote: > Thanks for your feedback, Dan. > > Engaging new contributors was one of the positive effects I had in mind > too. > > If we'd do refactorings per class/package, it should be good to handle. > We had good experience during the FindBugs initiative [1]. > > Thanks, > > Michael Brohl > > ecomify GmbH - www.ecomify.de > > > Am 13.02.20 um 17:55 schrieb Daniel Watford: > > Hi Michael, > > > > Improving the checkstyle/findbugs metrics could be a good theme for the > > February Community Days as these sorts of fixes are often low risk and > you > > get a lot of help from your IDE. > > > > These sorts of tasks are often a good way for new developers to get > > involved as they don't require in-depth knowledge of the code, as long as > > they stick to the principle of only renaming variables/constants, and > avoid > > too much code refactoring. > > > > The downside is that the quantity of changes to review can be high, and > > since many source code files would likely be modified, you would need > > reviewers who are able to respond quickly. But we could encourage > > developers to try and keep any 'variable rename sets' as small as > possible. > > > > Dan. > > > > On Thu, 13 Feb 2020 at 16:44, Michael Brohl <[email protected]> > > wrote: > > > >> Hi *, > >> > >> checkstyle currently reports a huge amount of errors. We currently have > >> an error count setup in the configuration to prevent the build from > >> failing because of the present errors. > >> > >> Some thoughts/questions to the community: > >> > >> * should we take an approach to fine-tune the configuration so that it > >> better fits the project style? > >> > >> As an example, constants are currently not allowed to be named "module", > >> "resource" etc. which is a common pattern in our code. Changing from > >> ^[A-Z][A-Z0-9]*(_[A-Z0-9]+)*$ to ^[a-zA-Z][a-zA-Z0-9]*(_[a-zA-Z0-9]+)*$ > >> would allow the common naming. > >> > >> The opposite approach would be to rename those to fit the default > settings. > >> > >> * should we start an initiative to remove the valid errors like we did > >> with the FindBugs initiative some time ago? > >> > >> > >> Thanks for your feedback, > >> > >> Michael Brohl > >> > >> ecomify GmbH - www.ecomify.de > >> > >> > >> > >
