Date   
I claim "bus factor" is mostly useless

Daniel Stenberg
 

Hi,

Since you've now added "bus factor" as a criteria, can someone please explain how this is valuable to users of open source projects?

All the availabe tools that determine this factor only run on code and check for commits or code churn etc. They can't tell the general "knowledge level" or how many people "understand" the code or particular areas? How many people read and deal with the code without sending back patches?

For a documented, proven, old, established open source project with an active maintainer, it is *easy* to have a bus factor that is less than two when checked by scripts like you encourage in the criteria, but yet if said person would be run over by a bus there's very little indications that the project would stall or die because of that.

The bus factor could perhaps be relevant if there were no docs, if the code was poorly written, uncommented or barely tested. But all those are *also* criteria...

So then. I hold up my finger and sense that more at least a few more people than me know my project. Is that a met criteria?

--

/ daniel.haxx.se

Formally announcing: silver/gold levels & internationalization

David A. Wheeler
 

All:

Nicko van Someren has written a very nice blog post about the recent enhancements to the Best Practice Badge program, in particular the higher silver/gold levels & our new support for internationalization: https://www.coreinfrastructure.org/news/blogs/2017/06/cii-best-practices-badge-program-announces-higher-level-certification-and

Very soon Marcus Streets will be giving a talk in Beijing about the CII and will be talking about the internationalized version of the application & other related materials.

I want to *SINCERELY* thank everyone here for all your help in making this possible. I especially want to give a shout out to our translators - you're amazing. The translators are: Yannick Moy, Wanganyu (Andrew Wang), Georg Link, Alexander "Alex" Meik Mikulla, Andy Distler, Takashi Kunai, Hiroyuki Fukuchi (HONSHA), Mieko Sato, Kitsune Ral (my sincere apologies for any omissions or incorrect names!).

The BadgeApp itself now meets the "silver" criteria, and we're shooting for gold.

--- David A. Wheeler

Re: Projects that received badges (monthly summary)

David A. Wheeler
 

Badgeapp:
This is an automated monthly status report of the best practices badge application covering the month 2017-05.
Here are some selected statistics for most recent completed month, preceded by the same statistics for the end of the month before that.
All:

This was the first completely-automatic monthly report from the badge application. I think it worked pretty well, and I think monthly status reports shouldn't be overwhelming. You'll notice that things are progressing nicely: Projects continue to start, continue to make progress, and a few manage to get a badge.

As always, you can see many more statistic here:
https://bestpractices.coreinfrastructure.org/project_stats

--- David A. Wheeler

Projects that received badges (monthly summary)

badgeapp@...
 

This is an automated monthly status report of the best practices badge application covering the month 2017-05.

Here are some selected statistics for most recent completed month, preceded by the same statistics for the end of the month before that.

Ending dates2017-04-292017-05-30
Total Projects744820
Projects 25%+277306
Projects 50%+224250
Projects 75%+177195
Projects passing7682

Here are the projects that first achieved a passing badge in 2017-05:

  1. Hyperledger Fabric at 2017-05-11 11:43:38 UTC
  2. aiengine at 2017-05-12 20:18:29 UTC
  3. The System Integrity Management Project (SIMP) at 2017-05-18 16:34:35 UTC
  4. nvm at 2017-05-22 20:06:10 UTC
  5. Hyperledger Sawtooth Distributed Ledger at 2017-05-23 19:00:58 UTC

We congratulate them all!

Do you know a project that doesn't have a badge yet? Please suggest to them that they get a badge now!

Internationalization & localization

David A. Wheeler
 

We are basically done internationalizing the BadgeApp.  It was a lot of work, but it means that people will be able to (eventually) see all the criteria text – and the rest of the system – in their preferred locale.  If we missed something (probable), pull requests are welcome.  The *hope* is that this will lead to more participation.

 

We now need it translated.  It currently has 635 segments that need translating.

 

We currently have native speakers working on French (fr), German (de), and Simplified Chinese (zh-CN).  We’ve reserved Japanese (ja).  If you’re a native speaker of any of those, please volunteer – with more than one person it doesn’t take long.

 

It’s not immediately obvious how to invoke this (though logged-in users can edit their profiles to change their default locale).  We don’t want to make it more obvious until we have at least one other locale’s translations done.  But it’s basically triggered via the URL, just add the locale at the beginning of the path (this even works at the top).  E.G.:

https://bestpractices.coreinfrastructure.org/zh-CN/projects/

 

--- David A. Wheeler

 

Higher criteria levels implemented. Names: passing+1 => silver, passing+2 => gold

David A. Wheeler
 

We’ve implemented the higher criteria in the BadgeApp, and given the higher levels official names.  The official name for “passing+1” is “silver”, and “passing+2” is “gold”.  That means that our 3 (current) levels are “passing”, “silver” and “gold”.

 

I’d earlier asked about names, but this is fundamentally picking the color of the bike shed, and I really don’t want to waste a lot of group time on that.  The real goal is, therefore, simply to “find something reasonable”.  I think these are reasonable names.  Rationale:

1. A “metal” theme is consistent with others’ level naming schemes (e.g., Olympic medals, LEED).

2. By using “silver” and “gold” we can later add a higher “platinum” level, so this is more future-proof.

3. Historically silver & gold have been used for currencies in many places around the world, so I expect that in many locales they will have an implied meaning of “valuable”.

4. By using “passing” (not “bronze”) for the first level we keep our current terminology & avoid suggesting that the first level is not very valuable.  In at least the US, “bronze” can imply “inferior”.  We want to avoid that!  Getting “passing” turns out to be rather challenging, and only about 10% of pursuing projects manage to get “passing”… so getting “passing” is certainly *not* inferior!

 

You can see the higher-level criteria by appending “/1” (silver criteria) or “/2” (gold criteria) to the project entry.  For example:

  https://bestpractices.coreinfrastructure.org/projects/1/1

  https://bestpractices.coreinfrastructure.org/projects/1/2

 

We’re intentionally not making this obvious yet in the UI, but it’s there!  Once we’re a little more satisfied, we’ll make it more obvious to select.  The current “future” criteria will probably disappear, because they’re now in higher-level criteria.

 

--- David A. Wheeler

 

Beginnings of internationalization now on production site

David A. Wheeler
 

FYI, the BadgeApp production site now has the beginnings of internationalization & localization.  We’ve begun with two locales besides English: French (fr) and Simplified Chinese (zh-CN).  It’s still early, but you can now see it live.

 

If anyone who is a *native* speaker in another locale would be willing to assist, please let me know.  Translation.io makes it relatively easy to edit.  You just use a web browser, and they provide “starter suggestions” based on past translations & Google translate.

 

URLs select the locale to display, and on login users are transitioned to their preferred locale (unless they’ve already selected one via the URL).  At the top level URLs are of the form “?locale=NAME”, otherwise the URLs are of the form “https://bestpractices.coreinfrastructure.org/LOCALE/...”.  These are fairly common conventions for locale selection.  E.G.:

* https://bestpractices.coreinfrastructure.org/?locale=zh-CN

* https://bestpractices.coreinfrastructure.org/zh-CN/project_stats

* https://bestpractices.coreinfrastructure.org/?locale=fr

* https://bestpractices.coreinfrastructure.org/fr/project_stats

 

It’s incomplete.  Internationalization involves a lot of little boring changes, so it’s taken a little time.  The main form for entering project data hasn’t been internationalized yet, and some email doesn’t use the correct locale yet.  Those are in progress.

 

My special & sincere thanks to Wang Anyu (locale zh-CN) and Yannick Moy (locale fr), who have been doing the translations.  Google translate & I did some of the initial French work, and all speakers of French are glad I’m not doing that any more J.

 

At this time the plan is leave project *justifications* (details) in English.  One problem is that reviewing justifications in arbitrary languages is, well, complicated.  But this *does* mean that a potential user of a project can see a project’s status for every criterion, in the preferred language of that user.  My hope is that this will encourage potential users to use the results of well-run projects.

 

--- David A. Wheeler

 

Projects that received badges (monthly summary)

badgeapp@...
 

This is an automated monthly status report of the best practices badge application covering the month 2017-04.

Here are some selected statistics for most recent completed month, preceded by the same statistics for the end of the month before that.

Ending dates2017-03-302017-04-29
Total Projects685744
Projects 25%+260277
Projects 50%+213224
Projects 75%+171177
Projects passing7176

Here are the projects that first achieved a passing badge in 2017-04:

  1. Xen Project at 2017-04-07 12:27:27 UTC
  2. doctest at 2017-04-12 12:00:12 UTC
  3. Chamilo at 2017-04-12 19:12:36 UTC
  4. App Store for Nextcloud at 2017-04-16 18:57:21 UTC
  5. The new pugachu website! at 2017-04-22 18:09:51 UTC

We congratulate them all!

Do you know a project that doesn't have a badge yet? Please suggest to them that they get a badge now!

Re: BadgeApp website internationalization

Mark Rader
 

David

You may also want to ask OWASP/ZAP what they use since they extensively internationalize. 

Mark

On Fri, May 5, 2017 at 1:04 PM, Wheeler, David A <dwheeler@...> wrote:
Dan Kohn:
> It may be worth considering this service, which is free for open source projects, if we invest further in i18n.
> https://translation.io/

Great idea.  I've requested an account.

We've often considered internationalization before, but Nicko recently asked us to actually add internationalization.

Machine translation isn't great, but it has gotten better over the years.  If we're going to support some locale X, I think it'd be useful to create machine translation as a first pass, include it in the distribution, and then have a human fix them over time.  That gives us an incremental approach, and where it makes sense I prefer incremental approaches over a "big bang" approach ("big bang" approaches have the risk of never finishing).

--- David A. Wheeler

_______________________________________________
CII-badges mailing list
CII-badges@lists.coreinfrastructure.org
https://lists.coreinfrastructure.org/mailman/listinfo/cii-badges

Re: BadgeApp website internationalization

David A. Wheeler
 

Dan Kohn:
It may be worth considering this service, which is free for open source projects, if we invest further in i18n.
https://translation.io/
Great idea. I've requested an account.

We've often considered internationalization before, but Nicko recently asked us to actually add internationalization.

Machine translation isn't great, but it has gotten better over the years. If we're going to support some locale X, I think it'd be useful to create machine translation as a first pass, include it in the distribution, and then have a human fix them over time. That gives us an incremental approach, and where it makes sense I prefer incremental approaches over a "big bang" approach ("big bang" approaches have the risk of never finishing).

--- David A. Wheeler

Re: BadgeApp website internationalization

Dan Kohn
 

It may be worth considering this service, which is free for open source projects, if we invest further in i18n.


On Fri, May 5, 2017 at 1:00 PM, Wheeler, David A <dwheeler@...> wrote:

We’ve made a first step towards internationalizing the BadgeApp application on the “master” git branch.

 

We have a volunteer for zh (Chinese).  If anyone else would be willing to help localize, that’d be great… please let me know what locale.  There’s a start on ‘fr’ (French), if someone who *actually* knows French could help that’d be great (for example).

 

For supported locales, you can request seeing the locale just by adding the locale at the beginning of the path.  E.g., for “fr” (French):

  https://master.bestpractices.coreinfrastructure.org/fr

  https://master.bestpractices.coreinfrastructure.org/fr/login

 

Only a few pages support internationalization, only a few locales are allowed right now (en, fr, zh), and we don’t have *good* translations yet (there are a few stub “fr” pages provided by Google Translate).  We haven’t yet implemented, in particular, internationalizing the criteria text.  It’s all in progress.

 

This is only for *presenting* the BadgeApp text.  When people type in justifications, that’s a different story.  :-).  That said, it’s possible to write text that is easier for a machine to translate, and that may be the best recommendation.

 

--- David A. Wheeler

 


_______________________________________________
CII-badges mailing list
CII-badges@lists.coreinfrastructure.org
https://lists.coreinfrastructure.org/mailman/listinfo/cii-badges




--
Dan Kohn <mailto:dan@...>
Executive Director, Cloud Native Computing Foundation <https://cncf.io/>
tel:+1-415-233-1000

BadgeApp website internationalization

David A. Wheeler
 

We’ve made a first step towards internationalizing the BadgeApp application on the “master” git branch.

 

We have a volunteer for zh (Chinese).  If anyone else would be willing to help localize, that’d be great… please let me know what locale.  There’s a start on ‘fr’ (French), if someone who *actually* knows French could help that’d be great (for example).

 

For supported locales, you can request seeing the locale just by adding the locale at the beginning of the path.  E.g., for “fr” (French):

  https://master.bestpractices.coreinfrastructure.org/fr

  https://master.bestpractices.coreinfrastructure.org/fr/login

 

Only a few pages support internationalization, only a few locales are allowed right now (en, fr, zh), and we don’t have *good* translations yet (there are a few stub “fr” pages provided by Google Translate).  We haven’t yet implemented, in particular, internationalizing the criteria text.  It’s all in progress.

 

This is only for *presenting* the BadgeApp text.  When people type in justifications, that’s a different story.  :-).  That said, it’s possible to write text that is easier for a machine to translate, and that may be the best recommendation.

 

--- David A. Wheeler

 

Starting to implement higher levels (#740) & internationalization (#739)

David A. Wheeler
 

We’ve gotten feedback on the proposed criteria for higher levels, and tried to respond where we could (thanks to everyone!):

  https://github.com/linuxfoundation/cii-best-practices-badge/blob/master/doc/other.md

 

The plan is now to *implement* this in the BadgeApp, which is issue #740:

  https://github.com/linuxfoundation/cii-best-practices-badge/issues/740

 

The current plan is to have completely different views for each level; that’s easier to understand & easier to implement.  E.g., /projects/1?level=0 would should the current “passing” level, while /projects/1?level=1 would show “passing+1” level.  The LF will have to bikeshed what they want “passing+1” actually named, but I’m expecting some sort of metal theme (silver/gold, gold/platinum, or whatever).

 

We also intend to internationalize the software (so that others can localize it), per #739:

  https://github.com/linuxfoundation/cii-best-practices-badge/issues/739

 

This won’t happen instantly, but I wanted to make sure everyone was informed!

 

--- David A. Wheeler

 

 

Re: Projects that received badges (monthly summary)

David A. Wheeler
 

Subscribers here have hopefully noticed a new kind of email, with the subject “[CII-badges] Projects that received badges (monthly summary)”.

 

This is a new feature.  The plan is that the BadgeApp will send an email once a month to this mailing list.  This email will provide some basic information about the past month, e.g., the projects that got a badge that month & some overall statistics.  Since there are many OSS projects, you shouldn’t expect to recognize most of the ones getting badges, but hopefully you’ll recognize a few (e.g., Xen got a badge in April – congrats!!!).  If a project got a badge but seems dubious for some reason, please let us know.  We do check passing projects, but an advantage of this monthly email is that it alerts more people about passing projects (which they can then review and challenge).  In any case, a monthly email should help you get a sense of what’s going on, with no effort on your part.

 

My *hope* is that emails that only show up once a month aren’t bothersome, especially since they’re simply an overall summary of key activity from that month.  All of us are busy, so I really don’t want to do anything that’s overwhelming to people.  Only a small percentage of projects are passing, but even if there’s a lot of growth, a single email (even if it’s long) should be no big deal.

 

I don’t want to overwhelm anyone, so I think we should keep it to this kind of information and (monthly) rate.  If you want more details about the status of badges, I suggest visiting the following:

1. Detailed statistics: https://bestpractices.coreinfrastructure.org/project_stats

2. The BadgeApp RSS feed:  https://bestpractices.coreinfrastructure.org/feed

3. Overview of projects (you can search, sort, etc.): https://bestpractices.coreinfrastructure.org/projects

 

If there are big objections, please let me know.  We haven’t made this actually report monthly (I wanted to make sure it worked first!), but that is the plan.

 

--- David A. Wheeler

 

 

From: cii-badges-bounces@... [mailto:cii-badges-bounces@...] On Behalf Of badgeapp@...
Sent: Tuesday, May 02, 2017 4:24 PM
To: cii-badges@...
Subject: [CII-badges] Projects that received badges (monthly summary)

 

This is an automated monthly status report of the best practices badge application covering the month 2017-04.

Here are some selected statistics for most recent completed month, preceded by the same statistics for the end of the month before that.

Ending dates

2017-03-30

2017-04-29

Total Projects

685

744

Projects 25%+

260

277

Projects 50%+

213

224

Projects 75%+

171

177

Projects passing

71

76

Here are the projects that first achieved a passing badge in 2017-04:

  1. Xen Project at 2017-04-07 12:27:27 UTC
  2. doctest at 2017-04-12 12:00:12 UTC
  3. Chamilo at 2017-04-12 19:12:36 UTC
  4. App Store for Nextcloud at 2017-04-16 18:57:21 UTC
  5. The new pugachu website! at 2017-04-22 18:09:51 UTC

We congratulate them all!

Do you know a project that doesn't have a badge yet? Please suggest to them that they get a badge now!

Projects that received badges (monthly summary)

badgeapp@...
 

This is an automated monthly status report of the best practices badge application covering the month 2017-04.

Here are some selected statistics for most recent completed month, preceded by the same statistics for the end of the month before that.

Ending dates2017-03-302017-04-29
Total Projects685744
Projects 25%+260277
Projects 50%+213224
Projects 75%+171177
Projects passing7176

Here are the projects that first achieved a passing badge in 2017-04:

  1. Xen Project at 2017-04-07 12:27:27 UTC
  2. doctest at 2017-04-12 12:00:12 UTC
  3. Chamilo at 2017-04-12 19:12:36 UTC
  4. App Store for Nextcloud at 2017-04-16 18:57:21 UTC
  5. The new pugachu website! at 2017-04-22 18:09:51 UTC

We congratulate them all!

Do you know a project that doesn't have a badge yet? Please suggest to them that they get a badge now!

How to disable emailed reminders with the mailing list password

David A. Wheeler
 

All:

 

FYI:  This mailing list is managed by the Linux Foundation using mailman.  By default, mailman sends a reminder message every month that includes your mailing list password (unique to each user and each list).  To our very NON-delight, that means a password is sent in the clear every month :-(.

 

The LF is well aware that the password security on mailman mailing lists is terrible.  However, the LF can't switch to Google Groups because it is inaccessible in China.  There are plans to implement better security for all its mailing lists, and that should solve the problem.  However, I don’t know when that will happen.

 

What you *can* do right now, if you’d like, is disable the monthly reminder. Go to:

  https://lists.coreinfrastructure.org/mailman/options/cii-badges

Log in, and go to “Get password reminder email for this list?”.  Select “no”, and push the button at the bottom “Submit my changes”.  Done!

 

In many cases email is transferred using an encrypted channel (TLS), which at least protects the email in motion (though not at rest).  I don’t know for certain if that’s true in this case; if someone can confirm or deny, that’d be great.  Password reset emails from the BadgeApp itself *are* encrypted in motion, when we can manage it, but that’s separate from this cii-badges mailing list.

 

I hope that helps…!

 

--- David A. Wheeler

 

Projects that received badges (monthly summary)

badgeapp@...
 

This is an automated monthly status report of the best practices badge application covering the month 2017-04.

Here are some selected statistics for most recent completed month, preceded by the same statistics for the end of the month before that.

Ending dates2017-03-302017-04-29
Total Projects685744
Projects 25%+260277
Projects 50%+213224
Projects 75%+171177
Projects passing7176

Here are the projects that first achieved a passing badge in 2017-04:

  1. Xen Project at 2017-04-07 12:27:27 UTC
  2. doctest at 2017-04-12 12:00:12 UTC
  3. Chamilo at 2017-04-12 19:12:36 UTC
  4. App Store for Nextcloud at 2017-04-16 18:57:21 UTC
  5. The new pugachu website! at 2017-04-22 18:09:51 UTC

We congratulate them all!

Do you know a project that doesn't have a badge yet? Please suggest to them that they get a badge now!

static_analysis: plan to add met_justification_required

David A. Wheeler
 

We intend to add a tweak to the criteria badging form, one which technically doesn’t change the criteria but will require a little more information from projects about static_analysis.  Comments welcome.

 

First, background.  One of the badge “passing” criteria is static_analysis:

* At least one static code analysis tool MUST be applied to any proposed major production release of the software before its release, if there is at least one FLOSS tool that implements this criterion in the selected language. (N/A allowed.) (Justification required for "N/A".)

https://github.com/linuxfoundation/cii-best-practices-badge/blob/master/doc/criteria.md#static_analysis

 

However, we now have several projects that are claiming that this criterion is “met” but it’s not obvious *how* this criterion is met.  I’m concerned that some projects might not really be meeting this criterion even though they’re claiming it, and of course that would be a problem.  In addition, we think it’d be useful for passing projects to provide examples for other projects, so that the other projects can consider those approaches.

 

So we intend to make a tweak to require that projects provide a *justification* for how they meet static_analysis.  A vast number do provide that justification, but a few don’t.  We want to do this gracefully, so here’s what we’re thinking:

* We’ll modify the form so that projects that are editing from here on must provide the justification.

* If a project already has a badge, we will *display* (for now) that they have a badge, even without this information, to give them time to update their entry.  We may send an email to just passing projects without justification in this field, to make sure they’re aware of it.

 

Technically this isn’t a change in the criteria, because it’s always been a MUST.  All that’s changing is that we want some information *justifying* that the criterion is met.  If you meet a criterion within a project you should be able to easily justify it.  For the vast majority of criteria this hasn’t been an issue, but this one seems to be more problematic.  This seems like the simplest way to inhibit problems.

 

Comments welcome!

 

--- David A. Wheeler

 

 

Presentation about the badging project!

David A. Wheeler
 

All – if you’re curious, here’s a presentation about the badging project’s status on Youtube:

   https://www.youtube.com/watch?v=0ubRjdm1QpY&feature=youtu.be

 

This is basically a recording of the presentation I gave at Lake Tahoe for the Linux Foundation.  I particularly focus on the criteria that are most likely to be missed by the projects that *almost* have a badge (see the presentation for details).

 

--- David A. Wheeler

 

Re: Should release_notes_vulns be relaxed from MUST to SHOULD?

Wang Anyu
 

Thanks David!

 

Based on our security practices, I suggested some criteria (#683 ~ #692) which mainly focused on crypto algorithm, secure delivery and code quality.

Please post comments, suggestions on these issues:

 

https://github.com/linuxfoundation/cii-best-practices-badge/issues/683

https://github.com/linuxfoundation/cii-best-practices-badge/issues/684

https://github.com/linuxfoundation/cii-best-practices-badge/issues/685

https://github.com/linuxfoundation/cii-best-practices-badge/issues/686

https://github.com/linuxfoundation/cii-best-practices-badge/issues/687

https://github.com/linuxfoundation/cii-best-practices-badge/issues/688

https://github.com/linuxfoundation/cii-best-practices-badge/issues/689

https://github.com/linuxfoundation/cii-best-practices-badge/issues/690

https://github.com/linuxfoundation/cii-best-practices-badge/issues/691

https://github.com/linuxfoundation/cii-best-practices-badge/issues/692

 

Thanks a lot!

 

Wang Anyu (Andrew)

 

 

发件人: cii-badges-bounces@... [mailto:cii-badges-bounces@...] 代表 Wheeler, David A
发送时间: 2017312 8:20
收件人: cii-badges@...
主题: [CII-badges] Should release_notes_vulns be relaxed from MUST to SHOULD?

 

All:  Issue #674 proposes to slightly relax the passing criterion “release_notes_vulns”, which currently says:

> “The release notes MUST identify every publicly known vulnerability that is fixed in each new release".

 

Details here:

> https://github.com/linuxfoundation/cii-best-practices-badge/issues/674

 

I think this is a different situation from the sites_https criterion, which required “The project sites (website, repository, and download URLs) MUST support HTTPS using TLS.”  We’ve received many requests to relax the sites_https criterion, and have not done so, even though there are a number of projects that didn’t meet it.  But that was fundamentally different.  People generally *did* agree that projects should be using HTTPS, even if they weren’t.

 

In contrast, the proposers are arguing that there are reasonable reasons to not do this.  This suggests that perhaps the criterion should be changed to a SHOULD instead of MUST (this would require them to provide a reason).

 

If you have comments, please post them on the issue:

https://github.com/linuxfoundation/cii-best-practices-badge/issues/674

 

We’ve also received a number of suggestions from Wang Anyu, which are posted on GitHub as issues.  I welcome anyone to comment on them, and I thank Wang Anyu for his thoughtful contributions.

 

Thanks!!

 

--- David A. Wheeler