We want to make sure that projects can display the current state of their badge. That means we need to make sure that this has great performance – in most cases asking for the badge value shouldn’t to

We now have a git branch ‘autofill’ with the start of automation. I want a simple automation framework so the code can be broken into smaller pluggable pieces (some implemented by others), instead of

The BadgeApp's "Gemfile" lists a lot of specific version numbers for the many gems (libraries) that we use. This makes it harder to update the libraries, and some (like Rails) have already released ne

The badge application is now beginning to automate entries for the form, so we now have a working automation framework. It doesn’t automate much yet; it current figures out the legal license in some e

Our application's test coverage is now up to 91% and our (main) dependencies are up-to-date (including Rails), per: https://github.com/linuxfoundation/cii-best-practices-badge Pull requests that impro

I think our markdown (.md) files should slowly migrate to using "normal" markdown only (which is what GitHub uses when it renders README and .md files), and NOT try to simultaneously support both norm

FYI: I’ve had to temporarily disable autofill. It works in test… but not in production (on Heroku), where it cannot save the project data if the repo is on GitHub. :-(. Clearly something important is

Well hooray, I *finally* found the problem with autofill, so autofill is now working on Heroku. That’s important; we have a lot of questions, but if we can fill out many automatically in many cases, i

Dan Kohn sent me an email asking if we should require *NOT* leaking private credentials in a repo. I'm completely on-board with this idea, so here's the issue tracker for discussion: https://github.co

Hi! I'm new to this mailing list. I'm a grad student studying quantitative metrics on open source software projects, a OSS developer and former project manager, and a contracting data scientist at Sel

FYI, here’s some information about nokogiri and BadgeApp. We *are* trying to make sure the application is deployed securely. Our development process for BadgeApp checks for known vulnerabilities in de

FYI – we’ve been busy! The “pulse” for this week starting today says that excluding merges, 3 authors have pushed 67 commits to the master branch; 47 files have changed and there have been 3,796 addit

In the BadgeApp we have to authenticate people. Here’s some thoughts on our current plans. In general we’ve tried to do things in simple and conventional ways for a Ruby-on-Rails app; that includes us

Hi, I wanted to thoroughly go over the criteria and comment on it for quite a while, but I haven't found the time. But after David's call today to look at them skimming over them I found a few things

All - we're reconfiguring the demo website to have multiple tiers and use a CDN. As a result, the "secret-retreat" site will stop working, and the main site https://bestpractices.coreinfrastructure.or

David A. Wheeler: >> "It is SUGGESTED that the project website use HTTPS, not HTTP. Future versions of these criteria may make HTTPS a requirement. (The badging application will show a warning for HTT

We have a number of other criteria proposals. I've created a new GitHub label, "criteria", for proposed criteria changes. You can see all the current ones here: https://github.com/linuxfoundation/cii-

Rdarw this berkeley girl named danielle yesterday wanted , my address to send me a google verification for 300 dollars I let her get my phone hers is 510 730 5503 Rdarw smart crew -- Sent fromGeze 209

Current draft criteria: >> "The project SHOULD support multiple cryptographic algorithms, so users can quickly switch if one is broken. Common symmetric key algorithms include AES, Twofish, Serpent, B

Hanno Böck: > Then one more philosophical issue. The text uses the term "OSS" or "Open Source". I know this is kinda an annoying issue, but this will turn away a certain audience. Given that I want es