Date   

Projects that received badges (monthly summary)

badgeapp@...
 

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

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

Ending dates2020-07-302020-08-30
Total Projects33093351
In Progress Projects 25%+12921312
In Progress Projects 50%+10701086
In Progress Projects 75%+875886
In Progress Projects 90%+666680
Passing Projects459464
Passing Projects, 25%+ to Silver166169
Passing Projects, 50%+ to Silver112114
Passing Projects, 75%+ to Silver7273
Passing Projects, 90%+ to Silver3131
Silver Projects1616
Silver Projects, 25%+ to Gold114115
Silver Projects, 50%+ to Gold2728
Silver Projects, 75%+ to Gold1313
Silver Projects, 90%+ to Gold77
Gold Projects77

Here are the projects that first achieved a Passing badge in 2020-08:

  1. taquito at 2020-08-04 23:03:03 UTC
  2. Eclipse Steady at 2020-08-14 09:36:40 UTC
  3. ludwig at 2020-08-16 18:00:30 UTC
  4. egeria at 2020-08-20 09:29:41 UTC
  5. rcosmo at 2020-08-24 04:35:51 UTC
  6. shortlink at 2020-08-24 08:25:12 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!


Proposed criteria introduction text

David Wheeler
 

All: Here's some proposed criteria introduction text.
Comments? It's lengthy, so I want to fix it up *before* our translators have
to deal with it.

The plan is to use this text to enable people to more easily see
all the criteria in *any* our supported natural languages.
People will be able to view "/criteria" on the BadgeApp and
see this (translated) introduction, and all the translated criteria.

--- David A. Wheeler

====

<h2 id='introduction'>Introduction</h2>
<p>
There is no set of practices that can <i>guarantee</i> that software
will never have defects or vulnerabilities.
Even formal methods can fail if the
specifications or assumptions are wrong.
Nor is there any set of practices that can guarantee that a project will
sustain a healthy and well-functioning development community.</p>
<p>
However, following best practices can help improve the results
of projects.
For example, some practices enable multi-person review before release,
which can both help find otherwise hard-to-find technical vulnerabilities
and help build trust and a desire for repeated interaction among
developers from different organizations.</p>
<p>
This page presents a set of best practices
for Free/Libre and Open Source Software (FLOSS) projects.
Projects that follow these best practices
will be able to voluntarily self-certify and show that they've
achieved the relevant
Core Infrastructure Initiative (CII) Best Practices badge.
Projects can do this, at no cost,
by using a web application (BadgeApp)
to explain how they meet these practices and their detailed criteria.</p>
<p>
These best practices have been created to:</p>
<ol>
<li>encourage projects to follow best practices,</li>
<li>help new projects discover what those practices are, and</li>
<li>help users know which projects are following best practices
(so users can prefer such projects).</li>
</ol>
<p>
The idiom "best practices" means
"a procedure or set of procedures that is preferred or considered
standard within an organization, industry, etc."
(source:
<a href="http://www.dictionary.com/browse/best-practice"
rel="nofollow">Dictionary.com</a>).
These criteria are what we believe are
widely "preferred or considered standard"
in the wider FLOSS community.</p>
For more information on how these criteria were developed,
see the <a
href="https://github.com/coreinfrastructure/best-practices-badge"
CII Best Practices badge GitHub site</a>.</p>
<p></p>
<h3 id='criteria_structure'>Criteria Structure</h3>
<p>
The best practices criteria are divided into three levels:<ul>
<li><b>Passing</b> focuses on best practices
that well-run FLOSS projects typically already follow.
Getting the passing badge is an achievement; at any one time
only about 10% of projects pursuing a badge achieve the passing level.
<li><b>Silver</b> is a more stringent set of criteria than passing but is
expected to be achievable by small and single-organization projects.
<li><b>Gold</b> is even more stringent than silver and includes
criteria that are not achievable by small or single-organization projects.
</ul>
<p>
Every criterion has a short name, shown below as superscripted
text inside square brackets.
<p></p>
<h3 id='criteria_other_projects'>Relationship to Other Projects</h3>
<p>
The Linux Foundation also sponsors the
<a href="https://www.openchainproject.org/"
rel="nofollow">OpenChain Project</a>, which
identifies criteria for a "high quality Free
and Open Source Software (FOSS) compliance program."
OpenChain focuses on how organizations can best use FLOSS and contribute
back to FLOSS projects, while the CII Best Practices badge
focuses on the FLOSS projects themselves.
The CII Best Practices badge and OpenChain work together to help
improve FLOSS and how FLOSS is used.</p>
<p>
<h3 id='criteria_automation'>Criteria Automation</h3>
<p>
In some cases we automatically test and fill in information
if the project follows standard conventions and
is hosted on a site (e.g., GitHub) with decent API support.
We intend to improve this automation in the future;
improvements are welcome!</p>
<p></p>
<h3 id='criteria_changes'>Changes over time</h3>
<p>
We expect that these practices and their detailed criteria will
be updated over time.
We plan to add new criteria but mark them as "future" criteria, so that
projects can add that information and maintain their badge.</p>
<p>
Feedback is <em>very</em> welcome via the
<a href="https://github.com/coreinfrastructure/best-practices-badge"
GitHub site as issues or pull requests</a>.
There is also a
<a href="https://lists.coreinfrastructure.org/mailman/listinfo/cii-badges"
rel="nofollow">mailing list for general discussion</a>.</p>
<p></p>
<h3 id='keywords'>Key words</h3>
<p>
The key words "MUST", "MUST NOT",
"SHOULD", "SHOULD NOT", and "MAY"
in this document are to be interpreted as described in
<a href="https://tools.ietf.org/html/rfc2119" rel="nofollow">RFC 2119</a>.
The additional term SUGGESTED is added.
In summary, these key words have the following meanings:</p>
<ul>
<li>The term MUST is an absolute requirement, and MUST NOT
is an absolute prohibition.</li>
<li>The term SHOULD indicates a criterion that is normally required,
but there may exist valid reasons in particular circumstances
to ignore it.
However, the full implications must be understood and carefully weighed
before choosing a different course.</li>
<li>The term SUGGESTED is used instead of SHOULD when the criterion must
be considered, but the valid reasons
to not do so are even more common than for SHOULD.</li>
<li>The term MAY provides one way something can be done, e.g.,
to make it clear that the described implementation is acceptable.</li>
</ul>
<p>
Often a criterion is stated as something that SHOULD be done, or is
SUGGESTED, because it may be difficult to implement or the costs
to do so may be high.</p>
<p></p>
<h3 id='criteria_achieving_badge'>Achieving a badge</h3>
<p>
To obtain a badge, all MUST and MUST NOT criteria must be met, all
SHOULD criteria must be either met OR unmet with justification, and
all SUGGESTED criteria have to be considered (it must be
rated as met or unmet, but justification is not required
unless noted otherwise).
An answer of N/A ("not applicable"), where allowed, is considered
the same as being met.
In some cases, especially in the higher levels,
justification and/or a URL may be required.</p>
<p>
Some criteria have special markings that influence this:<ul>
<li><b>{N/A allowed}</b> - "N/A" ("Not applicable") is allowed.
<li><b>{N/A justification}</b> - "N/A" ("Not applicable") is allowed
and requires justification.
<li><b>{Met justification}</b> - "Met" requires justification.
<li><b>{Met URL}</b> - "Met" requires justification with a URL.
<li><b>{Future}</b> - the answer to this criterion currently
has no effect, but it may be required in the future.
</ul>
<p>
A project must achieve the previous level to achieve the next level.
In some cases SHOULD criteria become MUST in higher level badges,
and some SUGGESTED criteria at lower levels become SHOULD or MUST
in higher level badges. The higher levels also require more
justification, because we want others to understand <i>how</i>
the criteria are being met.</p>
<p>
There is one implied passing criterion - every project MUST have
a public website with a stable URL. This is required to create
a badge entry in the first place.</p>
<p></p>
<h3 id='terminology'>Terminology</h3>
<p>
If you are not familiar with
software development or running a FLOSS project, materials such as
<a href="http://producingoss.com/"
rel="nofollow"><em>Producing Open Source Software</em>
by Karl Fogel</a> may be helpful to you.</p>
Here are a few key terms.
<p>
A <em>project</em> is an active entity that has
project member(s) and produces project result(s).
Its member(s) use project sites to coordinate and disseminate result(s).
A project does not need to be a formal legal entity.
Key terms relating to projects are:</p>
<ul>
<li>Project <em>members</em> are the
group of one or more people or companies who work together
to attempt to produce project results.
Some FLOSS projects may have different kinds of members, with different
roles, but that's outside our scope.</li>
<li>Project <em>results</em> are what the project members work together
to produce as their end goal. Normally this is software,
but project results may include other things as well.
Criteria that refer to "software produced by the project"
are referring to project results.</li>
<li>Project <em>sites</em>
are the sites dedicated to supporting the development
and dissemination of project results, and include
the project website, repository, and download sites where applicable
(see <a href="#sites_https">sites_https</a>).</li>
<li>The project <em>website</em>, aka project homepage, is the main page
on the world wide web (WWW) that a new user would typically visit to see
information about the project; it may be the same as the project's
repository site (this is often true on GitHub).</li>
<li>The project <em>repository</em> manages and stores the project results
and revision history of the project results.
This is also referred to as the project <em>source repository</em>,
because we only require managing and storing of the editable versions,
not of automatically generated results
(in many cases generated results are not stored in a repository).</li>
</ul>


--
--- David A. Wheeler
Director of Open Source Supply Chain Security, The Linux Foundation


Rename route "/criteria"->"/criteria_stats", /criteria to display criteria

David Wheeler
 

FYI:
I intend to soon rename the route "/criteria" to "/criteria_stats". We
can then use "/criteria" to display the actual criteria in the
selected locale. This is technically a change in the user-visible API,
but in practice I expect no impact.

Details:
https://github.com/coreinfrastructure/best-practices-badge/pull/1453
https://github.com/coreinfrastructure/best-practices-badge/pull/1454

--- David A. Wheeler
Director of Open Source Supply Chain Security, The Linux Foundation


Re: Renaming whitelist->acceptlist, blacklist->denylist

David Wheeler
 

All: Minor correction.
The more common term seems to be "allowlist" not "acceptlist" . E.g.:
https://www.zdnet.com/article/linux-team-approves-new-terminology-bans-terms-like-blacklist-and-slave/
So I plan to use "allowlist" everywhere, not acceptlist.

These are new words, so I didn't immediately notice the inconsistency.
I'll note that Google docs is *already* accepting allowlist as a single word.

--- David A. Wheeler
Director of Open Source Supply Chain Security, The Linux Foundation


Renaming whitelist->acceptlist, blacklist->denylist

David Wheeler
 

All:

This pull request:
https://github.com/coreinfrastructure/best-practices-badge/pull/1449
renames “whitelist” to “acceptlist” and “blacklist” to “denylist" everywhere
in the CII Best Practices badge material, including the criteria text.
Note that “a whitelist” becomes “an acceptlist” (where “a” becomes “an”).

This is technically a change to the criteria text, but it does not
change the *meaning* of the text in any way.

As always, if you have issues or see an error, please comment on the pull request.

Thank you!

— David A. Wheeler


Re: has anyone scripted doing updates to the CII site?

David Wheeler
 

On Aug 12, 2020, at 5:43 PM, HANSEN, TONY L <tony@...> wrote:
David, here are some questions not answered by that page:
* Does the REST API support basic authentication (over TLS)? Or some other HTTPS authentication method?
It uses TLS to authenticate the best practices server, as well as provide
confidentiality & integrity between client & server.
Login session management uses an HTTP cookie, not basic authentication.

A quick summary is “do what a human user would do”. You use a POST
to log in (with username & password), and get a cookie that represents your session.
That cookie can then be used (for a period of time) by sending it as part of
future requests, and grants you whatever your account is authorized to do.

* When using the PATCH verb, what is the JSON input expected to look like?
PATCH /projects/:id(.:format) projects#update
This is actually implemented by the underlying Rails framework. I’ll have to search,
but I believe there’s lots of sites that go into this.

— David A. Wheeler


Re: has anyone scripted doing updates to the CII site?

Tony Hansen
 

David, here are some questions not answered by that page:

* Does the REST API support basic authentication (over TLS)? Or some other HTTPS authentication method?

* When using the PATCH verb, what is the JSON input expected to look like?

PATCH /projects/:id(.:format) projects#update

Thank you

Tony

On 8/12/20, 9:22 AM, "David A. Wheeler" <dwheeler@...> wrote:

On Wed, Aug 12, 2020 at 12:10 AM Tony Hansen <tony@...> wrote:
...
> So I’d like a tool that could be used to do an identical update across a variety of CII projects. I’d like such a tool to take a list of CII project IDs, a field name and an update to make, such as
> Of course, it would need to log in correctly with an ID that has been authorized on each of the projects.
> I started writing such a tool, but I keep getting caught up with issues with CSRF.

Tony: We developed the API so it *could* be done. But I have never
needed to do it, so I don't have code lying around to do it.

I'd be delighted to help anyone who starts down that path. I believe
it shouldn't be *too* hard,
the problem is that it has to be exactly right or it gets (rightly) rejected.

The current API documentation may help:
https://github.com/coreinfrastructure/best-practices-badge/blob/master/doc/api.md
... and if such code is created, we should add it to the API documentation.

--- David A. Wheeler
Director of Open Source Supply Chain Security, The Linux Foundation


Re: has anyone scripted doing updates to the CII site?

David Wheeler
 

On Wed, Aug 12, 2020 at 12:10 AM Tony Hansen <tony@...> wrote:
...
So I’d like a tool that could be used to do an identical update across a variety of CII projects. I’d like such a tool to take a list of CII project IDs, a field name and an update to make, such as
Of course, it would need to log in correctly with an ID that has been authorized on each of the projects.
I started writing such a tool, but I keep getting caught up with issues with CSRF.
Tony: We developed the API so it *could* be done. But I have never
needed to do it, so I don't have code lying around to do it.

I'd be delighted to help anyone who starts down that path. I believe
it shouldn't be *too* hard,
the problem is that it has to be exactly right or it gets (rightly) rejected.

The current API documentation may help:
https://github.com/coreinfrastructure/best-practices-badge/blob/master/doc/api.md
... and if such code is created, we should add it to the API documentation.

--- David A. Wheeler
Director of Open Source Supply Chain Security, The Linux Foundation


has anyone scripted doing updates to the CII site?

Tony Hansen
 

I’m one of the many people working on the Linux ONAP (Open Networking Automation Platform) Project. We chose to pursue CII badges from the very beginning, but because of the size of the project, we chose several years ago to use separate CII projects for each of the ONAP sub-projects. We currently have close to 40 CII projects covering the ONAP sub-projects.

 

For all of the application-specific questions, we rely on our project team leaders to answer the questions. However, when we do something (say, updating our build infrastructure to better satisfy one of the Gold questions), we are faced with updating all 40 CII pages with an identical update. Getting the project team leaders to do the updates has proven unreliable, and doing the update one project at a time is tedious at best.

 

So I’d like a tool that could be used to do an identical update across a variety of CII projects. I’d like such a tool to take a list of CII project IDs, a field name and an update to make, such as

 

projects: 3777, . . .

mods:

    signed_releases_justification: "All release artifacts are signed by the Linux Foundation prior to release.."

 

Of course, it would need to log in correctly with an ID that has been authorized on each of the projects.

 

I started writing such a tool, but I keep getting caught up with issues with CSRF.

 

Has anyone successfully scripted doing updates to the CII site? If no one has, is anyone interested in working with me on such a tool?

 

Thank you

 

                Tony Hansen

                tony@...

 

 

 


Software report on Zephyr notes CII Best Practices badge

David Wheeler
 

All:

Here's a team report, as part of an architecture class, where they
examined open source software projects:
https://se.ewi.tudelft.nl/desosa2019/
If you look at a part that discusses Zephyr:
https://se.ewi.tudelft.nl/desosa2019/chapters/zephyr/#Autotools

You can see a reference to the CII Best Practices badge! It sayd:
"In conclusion, Zephyr could serve as a role model not only for
Real-time Operating Systems, but also for open-source software
projects in general. It is a good example of how successful management
of open-source contributions and a well defined and documented
architecture can ensure and retain the software’s quality. They follow
some of the [CII best] practices as can be seen from their gold badge
and this process goes a long way in avoiding technical debt."

This report came out in Dec 2019, so it's a bit dated in terms of the
Zephyr release they're looking at (pre-LTS). However, as Kate Stewart
noted, "it has some nice creative ways of showing the info... I like
how they did some of the classifications."

My sincere thanks to Brett, and Kate Stewart, for noticing this &
telling me about it!


--- David A. Wheeler
Director of Open Source Supply Chain Security, The Linux Foundation

--
--- David A. Wheeler
Director of Open Source Supply Chain Security, The Linux Foundation


CHAOSS Podcast #10 posted, notes the CII Best Practices Badge

David Wheeler
 

All:

CHAOSS Podcast #10 is now available, titled "Managing Risks and
Opportunities in Open Source with Frank Nagle & David A. Wheeler". The
hosts were Georg Link, Sean Goggins, and Kate Stewart.

The podcast mentions the CII Best Practices badge specifically.

You can hear it here:
https://podcast.chaoss.community/10

--- David A. Wheeler
Director of Open Source Supply Chain Security, The Linux Foundation


Mailing list server will be moving the Linux Foundation Single Sign-On (SSO)

David Wheeler
 

All:

The CII mailing list service is expected to soon switch to the “Linux Foundation Single Sign-on (SSO)” system
for logging in to the mailing list service. This is part of an LF effort to have *one* strong authentication service
for all LF work, so that people don’t need an endless numbers of accounts for LF work.

If you just receive emails, or you already use the LF SSO, then
there’ll be no change. Otherwise, when this change happens, you’ll need to do a
one-time account creation with the new LF SSO service. It should be very easy.

— David A. Wheeler


Please participate in the LF CII / Harvard LIST FOSS Survey!

David Wheeler
 

If you're a contributor to Free/Libre and Open Source Software (FOSS),
please participate in the LF CII / Harvard FOSS survey!

Here are more details, with a link at the bottom to the actual survey:

https://www.linuxfoundation.org/blog/2020/06/linux-foundation-harvard-announce-free-libre-and-open-source-software-foss-contributor-survey/

Thanks!

--- David A. Wheeler
Director of Open Source Supply Chain Security, The Linux Foundation


FYI: “The Impact of a Major Security Event on an Open Source Project:The Case of OpenSSL”

David Wheeler
 

All:

A recent paper looked at Heartbleed’s impact on OpenSSL: “The Impact
of a Major Security Event on an Open Source Project:The Case of
OpenSSL” by James Walden, 2020, https://arxiv.org/abs/2005.14242

Two interesting points:
* "the number of reported vulnerabilities is a poor indicator of
security." Basically, small numbers can mean "there's little to find"
OR "no one is looking.
* "Project activity and software engineering practices required by the
CII best practices badge may be better indicators of project
security.” They found that OpenSSL made a number of changes to earn
the badge, *AND* that those changes had stuck around years later.

Overall it's an interesting paper. They basically examine the OpenSSL
project before & after Heartbleed to see what they changed, and how it
changed their results.

It's nice to see the best practices badging project get positive comments :-).

--- David A. Wheeler
Director of Open Source Supply Chain Security, The Linux Foundation


"Why CII best practices gold badges are important":

David Wheeler
 

All - I thought you might like to know that I recently posted a blog
post titled "Why CII best practices gold badges are important":
https://www.linuxfoundation.org/blog/2020/06/why-cii-best-practices-gold-badges-are-important/

It's on the Linux Foundation's blog, so hopefully at least some others
will notice. The post emphasizes advantages of badges, including the
gold level.

People here already know this info, I think, but I thought you'd like
to know about efforts to let *others* know.

--- David A. Wheeler
Director of Open Source Supply Chain Security, The Linux Foundation


Re: The Linux kernel has earned a gold badge!

Kate Stewart
 

Excellent news!   Kudo's to Greg and the other contributors to making this happen!


On Wed, Jun 10, 2020 at 1:05 PM David Wheeler <dwheeler@...> wrote:
All: I want to formally congratulate the Linux kernel project for
earning a gold badge!! You can see their details here:
 https://bestpractices.coreinfrastructure.org/en/projects/34

The Linux kernel has been close for a while. The final one they
completed was to add some HTTP hardening headers to key websites.

Of course, a gold badge doesn't mean that there are no
vulnerabilities, or that it's impossible to improve their development
processes. Perfection is rare in this life. But it *does* mean that
they've implemented a large number of good practices to keep the
project sustainable, to counter vulnerabilities from entering their
software, and to address vulnerabilities when they are found. The
Linux kernel project take many steps to do this, and it's good to see.

The Linux kernel joins some of the few other gold applications, such
as the Zephyr project who have been at gold for a while. You can see
the current gold holders here:
https://bestpractices.coreinfrastructure.org/en/projects?gteq=300

My thanks to Greg KH, who spearheaded getting the badge "over the
finish line". Thank you for your effort.

I hope that this result will help inspire other projects to pursue -
and earn - a gold badge. Of course, the real goal isn't a badge - the
real goal is to make our software much more secure. But I think it's
clear that good practices can help make our software more secure, and
we want to praise & encourage projects to have good practices.

-- David A. Wheeler
    Director of Open Source Supply Chain Security, The Linux Foundation




Re: The Linux kernel has earned a gold badge!

Georg Link
 

This is fantastic news!
Congratulations to the Linux Kernel.

Thanks for highlighting this achievement.

Georg


On Wed, Jun 10, 2020 at 1:05 PM David Wheeler <dwheeler@...> wrote:
All: I want to formally congratulate the Linux kernel project for
earning a gold badge!! You can see their details here:
 https://bestpractices.coreinfrastructure.org/en/projects/34

The Linux kernel has been close for a while. The final one they
completed was to add some HTTP hardening headers to key websites.

Of course, a gold badge doesn't mean that there are no
vulnerabilities, or that it's impossible to improve their development
processes. Perfection is rare in this life. But it *does* mean that
they've implemented a large number of good practices to keep the
project sustainable, to counter vulnerabilities from entering their
software, and to address vulnerabilities when they are found. The
Linux kernel project take many steps to do this, and it's good to see.

The Linux kernel joins some of the few other gold applications, such
as the Zephyr project who have been at gold for a while. You can see
the current gold holders here:
https://bestpractices.coreinfrastructure.org/en/projects?gteq=300

My thanks to Greg KH, who spearheaded getting the badge "over the
finish line". Thank you for your effort.

I hope that this result will help inspire other projects to pursue -
and earn - a gold badge. Of course, the real goal isn't a badge - the
real goal is to make our software much more secure. But I think it's
clear that good practices can help make our software more secure, and
we want to praise & encourage projects to have good practices.

-- David A. Wheeler
    Director of Open Source Supply Chain Security, The Linux Foundation





--
Georg Link, PhD
(he/him)


The Linux kernel has earned a gold badge!

David Wheeler
 

All: I want to formally congratulate the Linux kernel project for
earning a gold badge!! You can see their details here:
https://bestpractices.coreinfrastructure.org/en/projects/34

The Linux kernel has been close for a while. The final one they
completed was to add some HTTP hardening headers to key websites.

Of course, a gold badge doesn't mean that there are no
vulnerabilities, or that it's impossible to improve their development
processes. Perfection is rare in this life. But it *does* mean that
they've implemented a large number of good practices to keep the
project sustainable, to counter vulnerabilities from entering their
software, and to address vulnerabilities when they are found. The
Linux kernel project take many steps to do this, and it's good to see.

The Linux kernel joins some of the few other gold applications, such
as the Zephyr project who have been at gold for a while. You can see
the current gold holders here:
https://bestpractices.coreinfrastructure.org/en/projects?gteq=300

My thanks to Greg KH, who spearheaded getting the badge "over the
finish line". Thank you for your effort.

I hope that this result will help inspire other projects to pursue -
and earn - a gold badge. Of course, the real goal isn't a badge - the
real goal is to make our software much more secure. But I think it's
clear that good practices can help make our software more secure, and
we want to praise & encourage projects to have good practices.

-- David A. Wheeler
Director of Open Source Supply Chain Security, The Linux Foundation


Should the badge app switch to a different translation management system (from translation.io)?

David Wheeler
 

Georg Link has proposed that we switch from the translation.io translation management system to a different system (in particular, Weblate). If you have thoughts on such a potential change, or information that could help in that decision, please add that information to this issue:

https://github.com/coreinfrastructure/best-practices-badge/issues/1430

Thanks!

— 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 2020-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 dates2020-04-292020-05-30
Total Projects31183171
In Progress Projects 25%+12331249
In Progress Projects 50%+10221034
In Progress Projects 75%+834844
In Progress Projects 90%+632639
Passing Projects434440
Passing Projects, 25%+ to Silver153157
Passing Projects, 50%+ to Silver106109
Passing Projects, 75%+ to Silver6869
Passing Projects, 90%+ to Silver3031
Silver Projects1515
Silver Projects, 25%+ to Gold106109
Silver Projects, 50%+ to Gold2525
Silver Projects, 75%+ to Gold1010
Silver Projects, 90%+ to Gold66
Gold Projects34

Here are the projects that first achieved a Passing badge in 2020-05:

  1. sonic-mgmt at 2020-05-01 23:55:10 UTC
  2. go-credentials at 2020-05-15 02:32:49 UTC
  3. worcs at 2020-05-19 15:03:07 UTC
  4. libBLS at 2020-05-23 15:24:41 UTC
  5. StackStorm at 2020-05-23 22:08:10 UTC
  6. googleAnalyticsR at 2020-05-28 10:02:28 UTC
  7. Meshroom at 2020-05-30 21:07:06 UTC
  8. PowerShellForGitHub at 2020-05-30 22:55:40 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!