Date   
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@...]:
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 :-)

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

David A. Wheeler
 

Georg Link [mailto:linkgeorg@...]:

That makes sense. How about displaying the percentage and clarifying what it means in a mouse-over tooltip?
I certainly agree we need to explain it!

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'm hoping someone will soon translate that text into German :-). Our French translator already got it done! (Hat-tip).

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.

--- David A. Wheeler

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

Georg Link
 

That makes sense. How about displaying the percentage and clarifying what it means in a mouse-over tooltip?


Georg

On Thu, Jun 14, 2018 at 10:47 AM, Wheeler, David A <dwheeler@...> wrote:

We certainly *could* display them that way, but there’s a lack of horizontal space.  The projects table is already really wide.  Besides, if you just want to see in progress/passing/silver/gold, we *also* show the badge icon (which does the same thing).

 

--- David A. Wheeler

 

From: Georg Link [mailto:linkgeorg@...]
Sent: Thursday, June 14, 2018 11:45 AM
To: Wheeler, David A
Cc: Daniel Stenberg; cii-badges@lists.coreinfrastructure.org
Subject: Re: [CII-badges] Improvement coming: Tiered percentage display in BadgeApp projects display

 

The percentages as proposed are logical.

 

Could we, instead of going above 100% (more than the whole), display current level plus percentage of next level?

 

Here are examples with interpretation:

* 95% (= 5% away from passing)

* passing + 80% (= 20% away from silver)

* silver + 30% (= 70% away from gold)

* gold (= achieved mastery)

 

In the background, we could still filter and sort based on the percentages that exceed the whole.

 

Georg

 


Daniel Stenberg [mailto:daniel@...]:
> But if Zephyr is *also* at the same time 93% of the gold criteria it will
> still only show 193%, right? That might not be as intuitive...
> I'm not objecting, just clarifying I guess.

You're absolutely correct, but I think it's okay.

It's theoretically *possible* for a project to have a higher percentage in gold than in silver, but it's very unlikely.  The gold criteria are generally harder than silver, and the silver criteria are harder than passing.  In addition, there's overlap (some "SUGGESTED" or "SHOULD" at lower levels become "MUST" at higher levels).

In addition, to get a higher-level badge you must meet the lower-level badge criteria, so this "capping" maps well to final badges.  For example, a "193%" correctly suggests that the project is very, very close to earning silver (200%).  A more general "average" could muddle things.

Of course, getting a *passing* badge is a significant achievement, and we don't want to take away from that.  We just want to make it easier for people to quickly get more information than they could before.

 


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

David A. Wheeler
 

We certainly *could* display them that way, but there’s a lack of horizontal space.  The projects table is already really wide.  Besides, if you just want to see in progress/passing/silver/gold, we *also* show the badge icon (which does the same thing).

 

--- David A. Wheeler

 

From: Georg Link [mailto:linkgeorg@...]
Sent: Thursday, June 14, 2018 11:45 AM
To: Wheeler, David A
Cc: Daniel Stenberg; cii-badges@...
Subject: Re: [CII-badges] Improvement coming: Tiered percentage display in BadgeApp projects display

 

The percentages as proposed are logical.

 

Could we, instead of going above 100% (more than the whole), display current level plus percentage of next level?

 

Here are examples with interpretation:

* 95% (= 5% away from passing)

* passing + 80% (= 20% away from silver)

* silver + 30% (= 70% away from gold)

* gold (= achieved mastery)

 

In the background, we could still filter and sort based on the percentages that exceed the whole.

 

Georg

 


Daniel Stenberg [mailto:daniel@...]:
> But if Zephyr is *also* at the same time 93% of the gold criteria it will
> still only show 193%, right? That might not be as intuitive...
> I'm not objecting, just clarifying I guess.

You're absolutely correct, but I think it's okay.

It's theoretically *possible* for a project to have a higher percentage in gold than in silver, but it's very unlikely.  The gold criteria are generally harder than silver, and the silver criteria are harder than passing.  In addition, there's overlap (some "SUGGESTED" or "SHOULD" at lower levels become "MUST" at higher levels).

In addition, to get a higher-level badge you must meet the lower-level badge criteria, so this "capping" maps well to final badges.  For example, a "193%" correctly suggests that the project is very, very close to earning silver (200%).  A more general "average" could muddle things.

Of course, getting a *passing* badge is a significant achievement, and we don't want to take away from that.  We just want to make it easier for people to quickly get more information than they could before.

 

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

Georg Link
 

The percentages as proposed are logical.

Could we, instead of going above 100% (more than the whole), display current level plus percentage of next level?

Here are examples with interpretation:
* 95% (= 5% away from passing)
* passing + 80% (= 20% away from silver)
* silver + 30% (= 70% away from gold)
* gold (= achieved mastery)

In the background, we could still filter and sort based on the percentages that exceed the whole.

Georg


Daniel Stenberg [mailto:daniel@...]:
> But if Zephyr is *also* at the same time 93% of the gold criteria it will
> still only show 193%, right? That might not be as intuitive...
> I'm not objecting, just clarifying I guess.

You're absolutely correct, but I think it's okay.

It's theoretically *possible* for a project to have a higher percentage in gold than in silver, but it's very unlikely.  The gold criteria are generally harder than silver, and the silver criteria are harder than passing.  In addition, there's overlap (some "SUGGESTED" or "SHOULD" at lower levels become "MUST" at higher levels).

In addition, to get a higher-level badge you must meet the lower-level badge criteria, so this "capping" maps well to final badges.  For example, a "193%" correctly suggests that the project is very, very close to earning silver (200%).  A more general "average" could muddle things.

Of course, getting a *passing* badge is a significant achievement, and we don't want to take away from that.  We just want to make it easier for people to quickly get more information than they could before.

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

David A. Wheeler
 

David A. Wheeler:
For example, Zephyr has completed passing, and is 93% to silver, so its
tiered percentage will show as "193%". I don't know of anywhere else with
this kind of measurement, but I think that provides a nice *short* but
*useful* status display, and it *seems* relatively intuitive.

Daniel Stenberg [mailto:daniel@...]:
But if Zephyr is *also* at the same time 93% of the gold criteria it will
still only show 193%, right? That might not be as intuitive...
I'm not objecting, just clarifying I guess.
You're absolutely correct, but I think it's okay.

It's theoretically *possible* for a project to have a higher percentage in gold than in silver, but it's very unlikely. The gold criteria are generally harder than silver, and the silver criteria are harder than passing. In addition, there's overlap (some "SUGGESTED" or "SHOULD" at lower levels become "MUST" at higher levels).

In addition, to get a higher-level badge you must meet the lower-level badge criteria, so this "capping" maps well to final badges. For example, a "193%" correctly suggests that the project is very, very close to earning silver (200%). A more general "average" could muddle things.

Of course, getting a *passing* badge is a significant achievement, and we don't want to take away from that. We just want to make it easier for people to quickly get more information than they could before.

--- David A. Wheeler