Date   

Re: Filling in implementation_languages

Georg Link
 

On Fri, Sep 14, 2018 at 1:24 PM David A. Wheeler <dwheeler@...> wrote:

A number of people want to know that or search for information that way.

 


Out of curiosity:
How do we know how prevalent it is to use the badge app to lookup implementation languages?
What other information do we know are many people looking for?
Do we know what they are using this information for?

My curiosity is fueled by my CHAOSS engagement. I'm trying to understand what the most useful metrics are and how we can quantify this usefulness. 

Thanks,
Georg


Re: Filling in implementation_languages

Georg Link
 

Thanks David,

I acknowledge the technical challenge of my idea and agree that personalized emails for every project may not be feasible.

How are badge creators usually notified of updates and changes to the badge webapp? Is there a mailing list? After making the change, we could send a generic information update and include a call to action to check their project badges and correct if necessary or remove the (CII estimate) qualifier.

Best,
Georg

On Fri, Sep 14, 2018 at 2:14 PM Wheeler, David A <dwheeler@...> wrote:
Georg Link:
> Could we 'stage' the change and send a notification email to the badge creators about the planned change to their entry? The badge creators can then add the correct languages and prevent the change or if they are okay with it do nothing and we apply the change. I assume that no response is agreement or not caring.
> I would want to avoid changing entries without notifying the badge creators first.

I normally avoid that also (unless there's falsehood/fraud).  The problem is that this involves a *lot* of badge entries (exactly 1,170).  Notifying that many people at once is a big effort, easily goes wrong, and could cause us to be identified as a spammer.  We also don't want to bother people unnecessarily.

I think that adding "(CII estimate)" has the same effect - that text should make it adequately clear that this data is not from the project, instead, it's a "CII estimate".

--- David A. Wheeler


Re: Filling in implementation_languages

David A. Wheeler
 

Georg Link:
Could we 'stage' the change and send a notification email to the badge creators about the planned change to their entry? The badge creators can then add the correct languages and prevent the change or if they are okay with it do nothing and we apply the change. I assume that no response is agreement or not caring.
I would want to avoid changing entries without notifying the badge creators first.
I normally avoid that also (unless there's falsehood/fraud). The problem is that this involves a *lot* of badge entries (exactly 1,170). Notifying that many people at once is a big effort, easily goes wrong, and could cause us to be identified as a spammer. We also don't want to bother people unnecessarily.

I think that adding "(CII estimate)" has the same effect - that text should make it adequately clear that this data is not from the project, instead, it's a "CII estimate".

--- David A. Wheeler


Re: Filling in implementation_languages

Georg Link
 

+1
I think this is a good idea.

Could we 'stage' the change and send a notification email to the badge creators about the planned change to their entry?
The badge creators can then add the correct languages and prevent the change or if they are okay with it do nothing and we apply the change. I assume that no response is agreement or not caring.

I would want to avoid changing entries without notifying the badge creators first.

Best,
Georg


On Fri, Sep 14, 2018 at 1:24 PM David A. Wheeler <dwheeler@...> wrote:

We let people fill in a list of implementation languages for their project, and more recently we’ve been auto-filling that information on new projects if they host on GitHub.  However, that means that on many projects we don’t have the implementation languages identified, and a number of people want to know that or search for information that way.

 

So I plan to “fill in” the “implementation_languages” information for projects on GitHub that don’t already list it.  GitHub’s language-guessing skills are less than perfect, so I plan to add “(CII estimate)” after the list in these cases. E.g., a project #93 might list:

  JavaScript, Ruby (CII estimate)

 

If a project finds that our estimate is wrong, they can simply edit that information just like any other entry.  Nothing will change if the project already provides us that information.

 

Let me know soon if that’s a problem!

 

--- David A. Wheeler

 


Filling in implementation_languages

David A. Wheeler
 

We let people fill in a list of implementation languages for their project, and more recently we’ve been auto-filling that information on new projects if they host on GitHub.  However, that means that on many projects we don’t have the implementation languages identified, and a number of people want to know that or search for information that way.

 

So I plan to “fill in” the “implementation_languages” information for projects on GitHub that don’t already list it.  GitHub’s language-guessing skills are less than perfect, so I plan to add “(CII estimate)” after the list in these cases. E.g., a project #93 might list:

  JavaScript, Ruby (CII estimate)

 

If a project finds that our estimate is wrong, they can simply edit that information just like any other entry.  Nothing will change if the project already provides us that information.

 

Let me know soon if that’s a problem!

 

--- David A. Wheeler

 


Re: Projects that received badges (monthly summary)

Georg Link
 

Whow! It's great to see this many new badge holders!

Congratulations to all!


On Wed, Sep 5, 2018 at 6:31 PM <badgeapp@...> wrote:

This is an automated monthly status report of the best practices badge application covering the month 2018-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 dates2018-07-302018-08-30
Total Projects16971804
Projects 25%+635682
Projects 50%+522561
Projects 75%+415447
Projects passing186205

Here are the projects that first achieved a passing badge in 2018-08:

  1. byte-data at 2018-08-03 06:07:09 UTC
  2. simgrid at 2018-08-04 20:33:44 UTC
  3. MortalityLaws at 2018-08-06 08:35:09 UTC
  4. DefectDojo at 2018-08-10 01:42:25 UTC
  5. fixedWidth at 2018-08-10 12:45:47 UTC
  6. simplexml at 2018-08-12 11:39:47 UTC
  7. fictional-octo-journey at 2018-08-13 17:34:03 UTC
  8. Setup- at 2018-08-13 17:58:32 UTC
  9. MOE at 2018-08-15 18:15:05 UTC
  10. Jaeger, a Distributed Tracing System at 2018-08-16 07:37:46 UTC
  11. p11-kit at 2018-08-21 10:45:12 UTC
  12. drake at 2018-08-24 04:07:56 UTC
  13. httptest at 2018-08-24 04:10:46 UTC
  14. Ribamar at 2018-08-24 16:18:08 UTC
  15. libsagui at 2018-08-24 23:04:47 UTC
  16. lua-http at 2018-08-26 16:16:52 UTC
  17. Insolar at 2018-08-29 12:38:31 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 2018-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 dates2018-07-302018-08-30
Total Projects16971804
Projects 25%+635682
Projects 50%+522561
Projects 75%+415447
Projects passing186205

Here are the projects that first achieved a passing badge in 2018-08:

  1. byte-data at 2018-08-03 06:07:09 UTC
  2. simgrid at 2018-08-04 20:33:44 UTC
  3. MortalityLaws at 2018-08-06 08:35:09 UTC
  4. DefectDojo at 2018-08-10 01:42:25 UTC
  5. fixedWidth at 2018-08-10 12:45:47 UTC
  6. simplexml at 2018-08-12 11:39:47 UTC
  7. fictional-octo-journey at 2018-08-13 17:34:03 UTC
  8. Setup- at 2018-08-13 17:58:32 UTC
  9. MOE at 2018-08-15 18:15:05 UTC
  10. Jaeger, a Distributed Tracing System at 2018-08-16 07:37:46 UTC
  11. p11-kit at 2018-08-21 10:45:12 UTC
  12. drake at 2018-08-24 04:07:56 UTC
  13. httptest at 2018-08-24 04:10:46 UTC
  14. Ribamar at 2018-08-24 16:18:08 UTC
  15. libsagui at 2018-08-24 23:04:47 UTC
  16. lua-http at 2018-08-26 16:16:52 UTC
  17. Insolar at 2018-08-29 12:38:31 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!


Application

Rohit travels & tours
 

rtacloud application


Improvements to the badging website

David A. Wheeler
 

FYI, we’ve made several improvements to the badging website.  I list them below, in case you’re interested.

 

--- David A. Wheeler

 

=======================

 

* We now directly support IPv6 and HTTP/2.  HTTP/2 in particular leads to a significant performance improvement for first-time visitors.  First-time visitors should typically get a page in <1sec, and after that page retrievals are on the order of 1/2 second (timings vary on page, network latency/bandwidth/location, etc.).  For example, when testing the front page on “master” using https://www.webpagetest.org/ for a first-time visitor, the median front page load time dropped to 0.784s (3 samples) compared to 0.937s (3 samples), for a speedup = old_time/new_time = 0.937/0.784 = 1.2x. That's because all the support materials that are cached load "simultaneously" resulting in a significant speed improvement.  Non-first-time visitors don’t get a boost, since after the first download of support files they just use their cache.  More broadly, we don’t want people to skip the site because it performs poorly.  We perform *far* better than *most* non-static sites.  My thanks to @tambry for the suggestion and help in getting this working.  https://github.com/coreinfrastructure/best-practices-badge/issues/1206

 

* We’ve switched to CircleCI API 2.0, which is good because the 1.0 interface stops working at the end of this month (in 2 days!).  My sincere thanks to Jason Dossett for getting that working!  https://github.com/coreinfrastructure/best-practices-badge/issues/1070

 

* We’ve fixed an accessibility issue with the “navigation bar” (hamburger) that was a problem for blind users on small-width devices (such as smartphones & tablets).  We want to be accessible! https://github.com/coreinfrastructure/best-practices-badge/issues/1217

 

* We now automatically fill in the implementation’s programming languages list for new projects if the project is hosted on GitHub.  The plan is to eventually support searches based on the programming language, but we have to have data for searching to be useful. https://github.com/coreinfrastructure/best-practices-badge/issues/943

 

 


Projects that received badges (monthly summary)

badgeapp@...
 

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

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

Ending dates2018-06-292018-07-30
Total Projects16271697
Projects 25%+607635
Projects 50%+506522
Projects 75%+404415
Projects passing185186

Here are the projects that first achieved a passing badge in 2018-07:

  1. SPARK 2014 at 2018-07-02 09:39:05 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: Projects in R - significant interest and uptick

Georg Link
 

This is great news. Thanks for sharing!

A few thoughts on the blog post. I throw them out here for comments.

I is great to see that the value of the badge is perceived by so many, even if they have not heard of the badge before the survey.


> The CII should be sure to reflect the existing quality criteria provided through CRAN.

Do we know what those criteria are? Is this something we can learn from and improve the badge with for everyone?
A quick look at CRAN did not reveal anything useful to me.


> Make it easier to recognize which criteria categories passed and by what percentage in a high level visual representation, perhaps incorporated into the badge itself.

Great suggestion, however: more data requires more space to display. I am inclined to dismiss this idea because anyone can follow the badge to our app and see which category is unfulfilled.


> Can the CII criteria be streamlined to reflect only the needs of R packages, including those that are more data and documentation than code?

This idea sounds like forking the CII badge and tweaking it for R. I see the appeal of this, but I think the badge has more value when it is uniform across all projects and not splintered into specialized versions for different types of projects. Next Ruby developers want their own badge flavor for gems and NPM their own flavor for npm packages ... While it still achieves the goal of promoting best practices, it impedes on the signaling effect of the badge as a recognized and trusted measure of open source project quality.


> gathers and presents lessons learned from other FLOSS projects so developers don’t need to re-discover them.

I seem to remember that we have a wiki page somewhere to collect stories. Is someone dedicated to continuing with following up with new badge owners to get their feedback? With roughly 5-10 new badges each month (based on the monthly email), if we had someone dedicated towards writing a blog post for each, we could have 1-2 success stories published each week. A quick 20 minute interview with someone from the project about the process (we should have the email on file to contact them) should provide some quotes to use in the blog post.


Best,
Georg

On Wed, Aug 1, 2018 at 3:33 PM, David A. Wheeler <dwheeler@...> wrote:
All: Here's information I think you'd all like to know.

There's a recent encouraging article, "Should R Consortium Recommend CII Best Practices Badge for R Packages: Latest Survey Results" by Mark Hornick (July 26, 2018) on the R Consortium Project blog:
https://www.r-consortium.org/blog/2018/07/26/should-r-consortium-recommend-cii-best-practices-badge-for-r-packages-latest-survey-results

Their survey found that 90% of survey respondants said "yes" to the question, "Will the CII Best Practices Badge Program provide value to the R Community's package developers or package users?" - with 77% saying it has benefit for both developers and users.   95% of respondents had never heard of the CII before, but 74% would be willing to try it.

As a result, we've recently had a significant uptick in the number of new projects who have started working on a badge, and many of them use the R programming language.  Overall stats here:
https://bestpractices.coreinfrastructure.org/en/project_stats

Some have already earned badges, e.g.:
* BAS https://bestpractices.coreinfrastructure.org/en/projects/2055
* PKNCA https://bestpractices.coreinfrastructure.org/en/projects/2054

Some other projects don't have a badge yet, but that's okay.  If they identify problems, and then work to fix them, that's kind of the point!

Anyway, I think that's a very positive development & I thought you would too.

--- David A. Wheeler





Re: Projects in R - significant interest and uptick

Kate Stewart
 

Very cool David!   Thanks for sharing.  :-)

On Wed, Aug 1, 2018 at 3:33 PM, David A. Wheeler <dwheeler@...> wrote:
All: Here's information I think you'd all like to know.

There's a recent encouraging article, "Should R Consortium Recommend CII Best Practices Badge for R Packages: Latest Survey Results" by Mark Hornick (July 26, 2018) on the R Consortium Project blog:
https://www.r-consortium.org/blog/2018/07/26/should-r-consortium-recommend-cii-best-practices-badge-for-r-packages-latest-survey-results

Their survey found that 90% of survey respondants said "yes" to the question, "Will the CII Best Practices Badge Program provide value to the R Community's package developers or package users?" - with 77% saying it has benefit for both developers and users.   95% of respondents had never heard of the CII before, but 74% would be willing to try it.

As a result, we've recently had a significant uptick in the number of new projects who have started working on a badge, and many of them use the R programming language.  Overall stats here:
https://bestpractices.coreinfrastructure.org/en/project_stats

Some have already earned badges, e.g.:
* BAS https://bestpractices.coreinfrastructure.org/en/projects/2055
* PKNCA https://bestpractices.coreinfrastructure.org/en/projects/2054

Some other projects don't have a badge yet, but that's okay.  If they identify problems, and then work to fix them, that's kind of the point!

Anyway, I think that's a very positive development & I thought you would too.

--- David A. Wheeler





Projects in R - significant interest and uptick

David A. Wheeler
 

All: Here's information I think you'd all like to know.

There's a recent encouraging article, "Should R Consortium Recommend CII Best Practices Badge for R Packages: Latest Survey Results" by Mark Hornick (July 26, 2018) on the R Consortium Project blog:
https://www.r-consortium.org/blog/2018/07/26/should-r-consortium-recommend-cii-best-practices-badge-for-r-packages-latest-survey-results

Their survey found that 90% of survey respondants said "yes" to the question, "Will the CII Best Practices Badge Program provide value to the R Community's package developers or package users?" - with 77% saying it has benefit for both developers and users. 95% of respondents had never heard of the CII before, but 74% would be willing to try it.

As a result, we've recently had a significant uptick in the number of new projects who have started working on a badge, and many of them use the R programming language. Overall stats here:
https://bestpractices.coreinfrastructure.org/en/project_stats

Some have already earned badges, e.g.:
* BAS https://bestpractices.coreinfrastructure.org/en/projects/2055
* PKNCA https://bestpractices.coreinfrastructure.org/en/projects/2054

Some other projects don't have a badge yet, but that's okay. If they identify problems, and then work to fix them, that's kind of the point!

Anyway, I think that's a very positive development & I thought you would too.

--- 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 2018-06.

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

Ending dates2018-05-302018-06-29
Total Projects15571627
Projects 25%+574607
Projects 50%+486506
Projects 75%+389404
Projects passing178185

Here are the projects that first achieved a passing badge in 2018-06:

  1. wavefile at 2018-06-01 18:47:50 UTC
  2. trade at 2018-06-03 03:33:01 UTC
  3. mat2 at 2018-06-06 22:15:58 UTC
  4. gopass at 2018-06-07 13:25:54 UTC
  5. NATS - The Cloud Native Messaging System at 2018-06-08 16:33:10 UTC
  6. LedgerSMB at 2018-06-24 21:40:49 UTC
  7. tigefa at 2018-06-25 12:06:01 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: Silver crypto (TLS) requirements - thoughts from Zephyr

Daniel Stenberg
 

On Wed, 27 Jun 2018, David Brown wrote:

The issue here is how to address things that aren't "applications". A project that is either a library, or an os/platform isn't necessarily in a position itself to enforce certificate verification, and it is up to whatever application someone writes using this library or platform.

In our specific case, Zephyr includes the mbed TLS library. We can certainly make sure that any helper libraries we provide do proper certificate validation, as well as make sure that the sample applications do things correctly. But, ultimately, it is just a library, and it is up to a given application to use it correctly.
I have the exact same situation in curl. We provide a library and a tool. That both speak TLS and both can disable certificate verification.

How do we best capture this with CII? The current wording effectively excludes libraries or operating systems from reaching Silver, which, I argue makes silver less useful. But, are there things these types of projects should do to make it more likely that applications using it will do things correctly?
I think if the application, library, tool, or framework that uses TLS does verifies certificates by default then it satisfies the requirement.

Sure, almost everything that speaks TLS also allows the user to shoot themselves in the foot and disable the verification but I consider that secondary and not as important as what it does if use it without anything explicitly disabled or switched off.

At least that's how I've viewed the requirements for curl.

--

/ daniel.haxx.se


Re: Silver crypto (TLS) requirements - thoughts from Zephyr

David Brown
 

On Wed, Jun 27, 2018 at 08:06:57AM +0200, Daniel Stenberg wrote:

I haven't seen any response or activity on this thread so I'm pinging this
to refresh the conversation. Would the above changes to the requirements be
palatable for the Silver TLS criteria?
I don't understand the proposed changes. They seem to introduce a huge loop
hole in the TLS requirements.

First: certificate verification is not just for protecting "sensitive data"
that client may send (and even determining what is "sensitive" is often very
hard); it also makes sure that what is received can be trusted to be from the
right sender and thus the contents can be trusted to be what the sender
intended it to be etc.

Then, I don't see how you can defer that requirement to someone else and get
away with it. As the suggested phrasing of this requirement goes, you can as a
work-around use a completely insecure TLS-using *separate* library/project but
as long as I write my application to not "directly use TLS" I can just select
N/A on this requirement and get a pass.
The issue here is how to address things that aren't "applications". A
project that is either a library, or an os/platform isn't necessarily
in a position itself to enforce certificate verification, and it is up
to whatever application someone writes using this library or platform.

In our specific case, Zephyr includes the mbed TLS library. We can
certainly make sure that any helper libraries we provide do proper
certificate validation, as well as make sure that the sample
applications do things correctly. But, ultimately, it is just a
library, and it is up to a given application to use it correctly.

How do we best capture this with CII? The current wording effectively
excludes libraries or operating systems from reaching Silver, which, I
argue makes silver less useful. But, are there things these types of
projects should do to make it more likely that applications using it
will do things correctly?

I don't think we want to allow an application to get past this
requirement, as you've stated, but I do think we need to capture that
some projects do include TLS, but aren't themselves using that
library.

David


Re: Silver crypto (TLS) requirements - thoughts from Zephyr

Daniel Stenberg
 

On Tue, 26 Jun 2018, Andy Gross wrote:

The software produced by the project MUST, if it supports TSL, perform TLS certificate verification by default when using TLS, including on subresources. <<If the software is not an application that directly uses TLS select “not applicable” (N/A).>>

The software produced by the project MUST, if it supports TLS, perform certificate verification before sending HTTP headers with private information (such as secure cookies). <<If the software is not an application that directly uses TLS, select "not applicable" (N/A)>
I haven't seen any response or activity on this thread so I'm pinging this to refresh the conversation. Would the above changes to the requirements be palatable for the Silver TLS criteria?
I don't understand the proposed changes. They seem to introduce a huge loop hole in the TLS requirements.

First: certificate verification is not just for protecting "sensitive data" that client may send (and even determining what is "sensitive" is often very hard); it also makes sure that what is received can be trusted to be from the right sender and thus the contents can be trusted to be what the sender intended it to be etc.

Then, I don't see how you can defer that requirement to someone else and get away with it. As the suggested phrasing of this requirement goes, you can as a work-around use a completely insecure TLS-using *separate* library/project but as long as I write my application to not "directly use TLS" I can just select N/A on this requirement and get a pass.

--

/ daniel.haxx.se


Re: Silver crypto (TLS) requirements - thoughts from Zephyr

Andy Gross
 

On 3 May 2018 at 15:28, Andy Gross <andy.gross@...> wrote:
David Wheeler:
> We do that already; several criteria have "if" clauses. E.g.:
> * If the software produced by the project requires building for use, the project
> * MUST provide a working build system that can automatically rebuild the
> * software from source code. [build]
> * The project MUST enable one or more compiler warning flags, a "safe" language
> * mode, or use a separate "linter" tool to look for code quality errors or
> * common simple mistakes, if there is at least one FLOSS tool that can implement
> * this criterion in the selected language. [warnings]
>
> Suggestions on an "if" clause for this case are welcome; we can then discuss
> them.

We've discussed this at some length in the Zephyr Security subcommittee and have
come up with the following changes:

I've listed the two requirements (Silver - Security #7 and #8) below with the
addition of an if clause to cover the Zephyr RTOS case.  The changes are
encased in << >>.

The software produced by the project MUST, if it supports TSL, perform TLS
certificate verification by default when using TLS, including on subresources.
<<If the software is not an application that directly uses TLS select “not
applicable” (N/A).>>


The software produced by the project MUST, if it supports TLS, perform
certificate verification before sending HTTP headers with private information
(such as secure cookies). <<If the software is not an application that directly
uses TLS, select "not applicable" (N/A)>

I haven't seen any response or activity on this thread so I'm pinging this to refresh the
conversation.  Would the above changes to the requirements be palatable for the Silver
TLS criteria?

Best regards,

Andy Gross
Zephyr Project
 


Re: Improvement coming: Tiered percentage display in BadgeApp projects display

David A. Wheeler
 

Georg Link [mailto:linkgeorg@gmail.com]:
I was thinking of a tooltip for each of the percentages, not on the table title. When you hover over the value 250% the tooltip would show "silver + 50% towards gold".
Oh, I see! Good idea. I added that as an issue:
https://github.com/coreinfrastructure/best-practices-badge/issues/1172

David A. Wheeler:
I'm hoping someone will soon translate that text into German :-).  Our French translator already got it done! (Hat-tip).
Georg Link:
Mockery! -- Maybe it worked and there is a German translation now :-)
I meant it as a good-natured challenge, but as long as the system works... :-).

--- David A. Wheeler


Re: Improvement coming: Tiered percentage display in BadgeApp projects display

Georg Link
 



On Thu, Jun 14, 2018 at 1:32 PM, Wheeler, David A <dwheeler@...> wrote:
Georg Link [mailto:linkgeorg@...]:


The way I *currently* resolved that was that I added following to the /projects page, just below the table:
> The "tiered %" field shows 300% for gold, 200% for silver, and 100% for passing, and adds progress after the highest-earned badge.

I didn't make that text a tooltip, because on smartphones tooltips on hyperlinks aren't obvious and they're tricky to activate (and this is a live hyperlink, since it lets you sort on the column).  We could *also* make it a tooltip, for the laptop/desktop users, where that isn't a problem.

I was thinking of a tooltip for each of the percentages, not on the table title. When you hover over the value 250% the tooltip would show "silver + 50% towards gold".

 
I'm hoping someone will soon translate that text into German :-).  Our French translator already got it done! (Hat-tip).

Mockery! -- Maybe it worked and there is a German translation now :-)

101 - 120 of 613