Topics

Good stuff - Criteria!


David A. Wheeler
 

Trevor Vaughan and Bob Basques recently posted some comments about OSS badges and their criteria on a different mailing list.

Their comments are reposted below. I have asked them to further discuss these things on this mailing list (which is actually intended for the purpose of discussing OSS criteria!).

--- David A. Wheeler




==============================================================
Trevor:

I'd like to sign the SIMP project up for it, what's the best way to begin?

=======================================================
David A. Wheeler:

For now, the best way to begin is to go to:
https://github.com/linuxfoundation/cii-best-practices-badge
and view the draft criteria; just click on criteria.md. You can go straight there by viewing:
https://github.com/linuxfoundation/cii-best-practices-badge/blob/master/criteria.md

Then, see if the SIMP project can meet all the criteria. If you don't meet any criteria, is it because it's a bad idea? Is it something SIMP should do, and if so, is SIMP willing to do it? Are there things SIMP does that you think SHOULD be criteria, but are not?

Feedback is then welcome, e.g., via issue trackers or its mailing list:
https://lists.coreinfrastructure.org/mailman/listinfo/cii-badges

We're implementing a web app to help, but it's not ready yet.

=================================================
Trevor:

When I looked at it after Kit's initial post, I *think* that we meet almost all of the criteria defined through even the proposed badges.
That said, I didn't really want to self-badge, I feel like some sort of official write up/review is necessary to make this more than the 'organic' label is worth at the grocer.

==============================================
Bob Basques:

Any thoughts here about inviting other organizations like OSGeo into this type of certification. The OSGeo incubation process has many of these elements already in place as requirements for their certification of OSS projects for example. With some slight nudging, they could be convinced to add some more, etc.

A couple of OSGeo projects I work with already fit 95+% of the criteria list. So this is a rather interesting topic for future "cert" types of tasks. There might also be some sort of reasoning behind getting a Badging system going in OSGeo circles as well, once the mentioned sub-classing gets underway.

=================================================
David A. Wheeler:

Well, it's not just "self-badge". You have to write up *why* you think you meet each criteria into a web app, allowing others to review your justification.

If you think that a different approach is needed longer-term, please, join the mailing list specifically for badging. For example, I can imagine people first entering the criteria for a badge, and then there could be a separate external processing for vetting that information. But that's only likely to happen if people speak up.

=====================================================
Trevor:

Hmm...I think that something like a '.yaml' file that I could drop into my repo with all of the answers and than a badge that I could link to for my project would be ideal.
This way, I can update things grammatically and via Git like I do with everything else.
The web app could simply hook that file, process it, and modify my badge(s) to be the correct hue of awesome.

====================================================
Bob Basques:

In my favorite project, GeoMOOSE, I could literally link to something on the web for each criteria point as far as filling out a form. I have to agree with Trevor on the point about independent reviews, which would be the positive aspect of all this IMO.


=======================================
Trevor:

Perhaps a peer review system? You put in your criteria and then all of the other participants pitch in to just verify (at a cursory level) that it's not all garbage?
Upvote/Downvote system that changes the color of your badge?
It's a good theory anyway.

========================================
Bob Basques:

Also, would/should be done on a regular schedule as well. bi-annual or yearly, etc.

=======================================
Trevor:

I was thinking quarterly, but that may be pushing it. I mean, I have over 100 repos as part of my project right now.

==============================================
Trevor:

Huh...actually, how would this work?
Would each of my repos get a badge, or would there be one badge to rule them all at the 'meta-project'?


David A. Wheeler
 

Trevor:
Hmm...I think that something like a '.yaml' file that I could drop into my repo with all of the answers and than a badge that I could link to for my project would be ideal. This way, I can update things grammatically and via Git like I do with everything else. The web app could simply hook that file, process it, and modify my badge(s) to be the correct hue of awesome.
Our first-cut at the web application will use a centralized database, where forms are filled out and the resulting data all stored in one place. But it could be later changed to do that. It can already output JSON, which is trivial to bidirectionally convert with YAML (if specifically YAML is important).

--- David A. Wheeler


Trevor Vaughan
 

The only thing that's important about YAML is the ability to have comments. You could use HOCON if you're bent on JSON-like syntax.

Thanks,

Trevor

On Tue, Sep 15, 2015 at 5:41 PM, Wheeler, David A <dwheeler@...> wrote:
Trevor:
> Hmm...I think that something like a '.yaml' file that I could drop into my repo with all of the answers and than a badge that I could link to for my project would be ideal. This way, I can update things grammatically and via Git like I do with everything else. The web app could simply hook that file, process it, and modify my badge(s) to be the correct hue of awesome.

Our first-cut at the web application will use a centralized database, where forms are filled out and the resulting data all stored in one place.  But it could be later changed to do that.  It can already output JSON, which is trivial to bidirectionally convert with YAML (if specifically YAML is important).

--- David A. Wheeler


_______________________________________________
CII-badges mailing list
CII-badges@...
https://lists.coreinfrastructure.org/mailman/listinfo/cii-badges



--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699

-- This account not approved for unencrypted proprietary information --


David A. Wheeler
 

The only thing that's important about YAML is the ability to have comments. You could use HOCON if you're bent on JSON-like syntax.
In this particular case, I don't see a need for a special comment syntax. Nearly all of the criteria will have a "justification" text field, and the project will have a description field. There will plenty of opportunities to provide textual information. This kind of information isn't just a comment on the data; it's a key part of the data. Since we're focusing on self-assertion, we want to make it easy for potential users to read the justifications for those assertions (so they can see if they believe it). If we later added support for independent vetting, again, those justifications would need to be there anyway.

If for some weird reason it was needed, you could just use JSON + “//” comments, then use JSMin on it. A few sources:
https://plus.google.com/+DouglasCrockfordEsq/posts/RK8qyGVaGSr
http://blog.getify.com/json-comments/

BadgeApp could also be trivially modified to read/write either JSON or YAML (or other syntaxes too). Currently ".json" is accepted for JSON, so ".yaml" could implement YAML. Let's get the basics implemented first, then, if people want YAML - patches welcome.

--- David A. Wheeler


David A. Wheeler
 

Trevor:
Perhaps a peer review system? You put in your criteria and then all of the other participants pitch in to just verify (at a cursory level) that it's not all garbage? Upvote/Downvote system that changes the color of your badge? It's a good theory anyway.
You really need a significant number of participants to make that work well. I think it's better to start with self-assertion, and if there's real buy-in, add a vetting process.


Huh...actually, how would this work?
Would each of my repos get a badge, or would there be one badge to rule them all at the 'meta-project'?
We say "project"; different projects work differently. Some projects have a single repo, while some have a few tightly-connected repos (e.g., they may have a separate repo for the test suite, a separate one for web app deployment, etc.). We currently have room for a single URL for a repo, but that's not expected to be an issue; you can always just point to the "main" repo for a project (or create a meta-repo for closely-tied repos).

That said, if you say "meta-project" it's unlikely that it's a single project, and thus it's probably better to split them up.

--- David A. Wheeler