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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

There have been a number of code-level changes recently, including ones that I hope will make it easier for others to get involved. I documented in doc/INSTALL.md the steps to install a development en

Here’s where I *think* we are going in terms of naming levels. First, the small badge (to show on GitHub, etc.) will show "cii best practices" - all lower case. Dan made the interesting observation th

Hi David, I noticed that coding style guidelines are only a SHOULD. Colin Percival did an experiment with FreeBSD where he divided the code into 50% stylish / 50% not-stylish based on the code's consi

hi everyone, looks like there's a lot of activity at the moment, there is currently a link on readme.md for the BadgeApp Implementation notes. I see that we now have the flair / badge on readme.md. Is