Re: Finally completed badge, feedback on process


Daniel Stenberg
 

On Mon, 22 Aug 2016, Christopher Sean Morrison wrote:

2) Taking a position on distributed vs centralized version control is contemporary flamebait, both with merit and downsides.
Which critieria are you saying is taking a position on this?

3) Most of the SUGGESTED items devalue the badge through dilution. Some could graduate to SHOULD (e.g., those under Quality) while the remainder offer little to no value (as they have no bearing on the badge and only increase burden). I would recommend removing the non-Quality ones.
Having filed details on three projects so far, I agree with this.

6) Treating warnings as errors shouldn’t be a suggestion. Projects SHOULD be maximally strict, treating warnings as errors, with minimal exceptions (e.g., less than 1 exemption per 100 files). Frankly, I think it should be a MUST.
"maximally strict" is not a binary option, though. In many languages you can select levels of compliance or which standard to use for warnings. Like in C, lots of things in the older standard cause warnings in the newer etc. Compilers these days also allow warnings as help, they don't necessarily identify errors but *possible* errors. Would a single warning about an suspected source code indentation problem be a reason for a project to not follow best practices?

Also, warnings on which platforms? I work on projects that build on virtually every architecture and operating system that run on 32bits. Making them all build warning-free everywhere is if not impossible (in some cases the warnings are literally impossible to fix since they're mutually exclusive on different platforms), not something that would benefit the project or improve the source code.

My (so far) two listed 100% projects would not be 100% if this would be a MUST and say "on all platforms". And in fact, that would make it really hard for a very large number of portable C and C++ projects.

7) The “BadgeApp” title on individual badging pages make for a terrible title when sharing with others (e.g., via Facebook). Suggest something like “CII’s Best Practices Badge for $project_name"
Agreed! It is also somewhat related to: https://github.com/linuxfoundation/cii-best-practices-badge/issues/463 "Add support for large badge"

I would like a badge that is more self-explanatory. I think the current incarnation isn't very suitable stand-alone in a non-technical environment, like for example a project's front web site page.

--

/ daniel.haxx.se

Join CII-badges@lists.coreinfrastructure.org to automatically receive all group messages.