Topics

BadgeApp: Proposed table field implementation approach


David A. Wheeler
 

Here's a technical approach for implementing the "BadgeApp" application that I think would be useful. The goal is to make the application DRY by generating the form directly from the criteria text. That way, if we edit the text, the application with follow, and we can continue to edit the criteria in a simple markdown format.

I dreamed this up in just a few minutes, so I have no claims that this is the best possible approach; it's just something to start with. Alternative approaches welcome. Sam, in particular, I'd love to hear your thoughts.

--- David A. Wheeler

============================================================

The application should be able to generate the form directly from the markdown of the criteria text. Extract the portion about the criteria (e.g., starting with "Basic best practices"). Every bullet with a MUST, MUST NOT, SHOULD, or RECOMMENDED will have a matching [fieldname] entry (note that [fieldname] may have a dagger after it). Change "fieldname" by converting all "-" to "_".

If the fieldname ends in "_url", it records a URL, and there are no other fields. To get credit for such a URL, it needs to begin with "https?://", NOT include a "?" (that will counter some attempts to use BadgeApp to attack other systems), and that URL needs to be readable. Empty URLs for MUST requirements should be highlighted somehow.

Otherwise, the fieldname records Yes/No/(blank) that users must directly assert, and there is at least one other field that users can enter text into: fieldname + "_justification". *If* we have automated that field, then there is a field named fieldname + "_auto" that records an automated result justifying that it meets the criteria. Any criteria with a MUST, MUST NOT, SHOULD, or RECOMMENDED gets credit if the fieldname is "Yes" and (1) fieldname_auto justifies it, OR (2) filename_justification is nonblank and includes at least one URL (which is supposed to be a pointer to supporting information).

To get the badge, you need a URL or "Yes" in every MUST/MUST NOT/SHOULD/RECOMMENDED bullet for the (one) badge. I recommend that we show % progress as people fill them in the information, it'll give people a sense of progress (increasing the likelihood they'll finish).


Alton Blom
 

Sounds good, what're your thoughts on SHOULD and RECOMMENDED criteria?

If a project has valid reasons not to meet one of these criteria, will they just select Yes and provide a justification url or No and a justification url?  Whatever the situation it'll need to be clear in the app which way to respond.  Maybe a third option is available for SHOULD/RECOMMENDED criteria called "ignored".

I like the idea of % progress as they fill in the information.

On Sat, Sep 12, 2015 at 7:54 AM, Wheeler, David A <dwheeler@...> wrote:
Here's a technical approach for implementing the "BadgeApp" application that I think would be useful.  The goal is to make the application DRY by generating the form directly from the criteria text.  That way, if we edit the text, the application with follow, and we can continue to edit the criteria in a simple markdown format.

I dreamed this up in just a few minutes, so I have no claims that this is the best possible approach; it's just something to start with.  Alternative approaches welcome.  Sam, in particular, I'd love to hear your thoughts.

--- David A. Wheeler

============================================================

The application should be able to generate the form directly from the markdown of the criteria text.  Extract the portion about the criteria (e.g., starting with "Basic best practices").  Every bullet with a MUST, MUST NOT, SHOULD, or RECOMMENDED will have a matching [fieldname] entry (note that [fieldname] may have a dagger after it).  Change "fieldname" by converting all "-" to "_".

If the fieldname ends in "_url", it records a URL, and there are no other fields.  To get credit for such a URL, it needs to begin with "https?://", NOT include a "?" (that will counter some attempts to use BadgeApp to attack other systems), and that URL needs to be readable.  Empty URLs for MUST requirements should be highlighted somehow.

Otherwise, the fieldname records Yes/No/(blank) that users must directly assert, and there is at least one other field that users can enter text into: fieldname + "_justification".  *If* we have automated that field, then there is a field named fieldname + "_auto" that records an automated result justifying that it meets the criteria.  Any criteria with a MUST, MUST NOT, SHOULD, or RECOMMENDED gets credit if the fieldname is "Yes" and (1) fieldname_auto justifies it, OR (2) filename_justification is nonblank and includes at least one URL (which is supposed to be a pointer to supporting information).

To get the badge, you need a URL or "Yes" in every MUST/MUST NOT/SHOULD/RECOMMENDED bullet for the (one) badge.  I recommend that we show % progress as people fill them in the information, it'll give people a sense of progress (increasing the likelihood they'll finish).

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