|
Re: Filling in implementation_languages
Georg Link
On Fri, Sep 14, 2018 at 1:24 PM David A. Wheeler <dwheeler@...> wrote:
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:
|
||||||||||||||||||
|
|
||||||||||||||||||
|
Re: Filling in implementation_languages
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 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:
|
||||||||||||||||||
|
|
||||||||||||||||||
|
Filling in implementation_languages
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:
|
||||||||||||||||||
|
|
||||||||||||||||||
|
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.
Here are the projects that first achieved a passing badge in 2018-08:
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
rtacloud application
|
||||||||||||||||||
|
|
||||||||||||||||||
|
Improvements to the badging website
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.
Here are the projects that first achieved a passing badge in 2018-07: 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.
|
||||||||||||||||||
|
|
||||||||||||||||||
|
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.
|
||||||||||||||||||
|
|
||||||||||||||||||
|
Projects in R - significant interest and uptick
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.
Here are the projects that first achieved a passing badge in 2018-06:
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.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
On Wed, Jun 27, 2018 at 08:06:57AM +0200, Daniel Stenberg wrote:
The issue here is how to address things that aren't "applications". AI haven't seen any response or activity on this thread so I'm pinging thisI don't understand the proposed changes. They seem to introduce a huge loop 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:
I don't understand the proposed changes. They seem to introduce a huge loop hole in the TLS requirements.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).>>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? 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: 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
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: Georg Link: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 :-)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@...]: 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 :-)
|
||||||||||||||||||
|
|
