Sketching a Process for Sharing / Getting Feedback on Certification Drafts

Our team is actively refining the specifications for the Creative Commons Core Certification and the derivative versions for Libraries, Government, and Education based on discussions our meetings in May in Washington DC.

In that meeting we worked from a Draft 1.1 version developed in May 2015 by a Creative Commons team, represented in a spreadsheet so big that to see it all, you cannot read it:

It was effective in Washington to work from a version printed on something like an 6 foot wide sheet of paper. These represents a structure of “modules” each of which has a series of Performance Objectives, each of those with a list of sub enabling objectives. The work in D.C. was to refine the core, and then for each specialized certificate, identify which parts were relevant, and what was missing if anything.

What’s not in these spreadsheets are the potential OERs that could be used to teach the concepts nor the ideas for what kinds of assessable activities people might do to demonstrate their proficiency.

Our work now is to publish the revised certifications in a format that (a) people can read/review and (b) that they can provide feedback, resource suggestions, etc.

CC0 licensed pixabay image by jarmoluk

It’s no surprise that the most maybe the most accessible, understood form for this might be a document. Put aside the fountain pens and papers, but even in Google Docs, how far beyond parchment are we going?

I’ve been working on a few demonstration projects to “bust out of the document”; in preparation for a meeting past week with Paul Stacey, I did something that has proven helpful for me in this project. I took out paper and pen (not fountain) and sketched a potential “system” to tie together some key parts.

These are just ideas at this stage, and I elaborate below.

Alan’s sketch of a certification draft publishing / feedback system

There Need Not Be Just One Public Representation

While I may poke fun at the old document format, I do recognize it is a practical means to share it in a format that someone can scan and take in from a single spot. So there will be a document version of each certification.

Paul has been drafting a visual way to organize a high level view of the core certification components:

Each box then links down document to text with more detail. And the specialized versions built on this would “de-select” un-needed parts by removing color or adding new boxes as needed.

As a shared Google document, our team can of course modify as needed. And while these documents do have a versioning system built in, there is but one track of changes to revert to. And the changes will grow in complexity as we fill in detail.

And then what do we do about soliciting input? Yes, there are commenting tools built in, but for more than a few participants, this can get messy, and often people do not even know how to enter comments.

To me, a document version is ideal for reading/reviewing, but lesser so for collecting feedback, suggestions, and also managing all of this content.

Feedback / Suggestion Form

Our team started collecting ideas for OERs we might use to help teach/assess parts of the certification process. So we started with a document. It grew. Some people made their own documents. Documents have no structure for their information. Then they sprawl.

In thinking about asking the public for suggested resources, I felt a Google Form would serve better; we can structure the input, it gets saved into a Spreadsheet where we can also add administrative fields (e.g. to marl which ones should be used, where it should be used).

So I whipped up a demo:

This was really done for collecting resources, but it could be broader for getting general feedback. I initially saw a giant menu for selecting the specific objective it should be applied to, but this seems to be something our team should do on the back end.

We can do something useful with google forms; there are ways to generate links that have certain elements “pre-filled”, so we could have a link if we are targeting people working on the Government Specialized Certificate that it’s box is checked or maybe if we are asking for resources specifically related to the Legal Implementation Module we can link to the form with that module pre-selected.

And thus, the link for resource suggestions could possibly be in the document version of the drafts.

Feedback Via A WordPress / Web Version

A Form/Spreadsheet is reasonable for collecting/organizing resources. But what about more feedback about the specific objectives? We need to develop an introduction to explain the objectives beyond a title.

For example, under the CC License Suite Module (Module 3) we have Objective 3.8 “Know Difference Between CC0 vs PDM” — Is it clear what this is? Is it clear why this is important? And then within the objectives we are going to seek ideas on activities could be done that could be used to assess understanding.

For me, this open-ended type feedback might be better collected through the familiar format of a blog comment at the level of the Performance Objectives. I built out a basic prototype of how this would work (please ignore the filler text generated by Bacon Ipsum), this is just a demo:

prototype for a certification draft presented in wordpress

I should note that the structure of all of this is driven by the parent-child structure relationship of WordPress Pages, making use of the Page-List plugin to dynamically create that menu, based on a Page Structure of:

The beauty here is that if we change the order, name of any of the pages, the menu is updated everywhere.

From the main entry page you can drill down into any module– the only one I have set up is Module 1 Copyright Basics, so try that one.

Prototype for Module 1, Copyright Basics

So we have a place for a introduction to copyright basics (again now just bacon related filler text), and on the side, a navigation to the seven objectives.

Again, this menu is created automatically by the WordPress Page Structure, so if we rename, move around, add, delete, this navigation reflects those changes:

When we go to the level of an objective, say 1.4 Define Public Domain we are that detail level we hope to collect input.

Prototype for display of single objective

So here we hope to add and get input into the wording of the introduction. Listed below are the enabling objectives as reference, followed by a list of hopefully expanded open OERs, and ideas for activities that might be done to demonstrate proficiency in defining the Public Domain.

And at the bottom, for these pages, I was able to do a little bit of code wrangling to modify the typical blog comment form so it is more specific to this part of the site:

Modification of the default WordPress comment form

(We could also add a button / link to the Google form for resource suggestions).

At this level/volume of detail, a document grows unwieldy, so it works better to have it broken into segments.

Of course, this information goes into WordPress, and will need to be reviewed and added somewhere to … well that is next.

I Believe in GitHub, But Will Others?

From the first description by Paul Stacey about this project, the idea of forked content and GitHub management called to me, even if my level of experience was at medium level. Why? There is intended to be a core certification, common to all, and then versions modified for Libraries, Government, and Education.

That totally says “forking”. And then there is the idea that the certification materials, processes would be openly shared, so other entities could conduct training, or make new versions. Again, this is a forking of something that has beeb forked.

Finally, just looking at what I have been outlining, a draft of the certification specifications, has a level of detail that managing input, changes is beyond what is feasible in a document mindset, again says that GitHub’s management, reversion on multiple branches to any portion, is a reasonable way to manage the project.

Yet, just saying GitHub, much less showing anyone the interface, is enough to send most people running back to their parchments.

One of my first efforts on the project was an attempt to recast the Giant Certification Draft 1.1 Spreadsheet into a one screen interface AND to add the ability to adding resource suggestions and/or direct editing.

I did pull it off, using some open Javascript libraries, and published via GitHub pages. It looks similar to the WordPress version, here is a view of the Core Certification “map”:

Clicking on one Objective in a module, opens up it’s content in an accordion:

A look at one objective, 1.4 Define Public Domain

Most people of course do not want to edit HTML to contribute, so made the main link open up a GitHub Issue, which is like a … blog comment form.

There is a template inside meant to guide the input. It’s crude, and it does mean that someone needs to create a GitHub account (which is simple BTW). But we thought maybe with enough explanation, people might take it on.

I did a demo at our DC meeting, and there was interest and receptive comments. I blogged about it.

And… so far no one, not even my collaborators have tried this out.

Still, I am not giving up.

The reason is the management tools and ways to show progress that GitHub offers. So all issues submitted go into a place where they can be managed and actions taken on:

The GitHub interface for issues

An example issue was a technical problem, but could easily be a resource suggestion or an added idea for an activity for a module:

sample issue

Below are a series of messages as it is acted on, and can also include comments as a discussion as things progress

Activity taken on an issue

Because the person who entered this created a GitHub account, one benefit is we know who is contributing to the project. But for that person, that can also see and get notified as actions are taking on what they submitted. As manager of this project, I can assign other team members to take care of the issue, and it can be given different status flags to track in the system.

One of the nifty tools that we can use as an add-on called Waffle that shows in a more friendly way, the status of issues. Here is our “Waffle” with a few test messages to demonstrate how it works:

Collaborators on the project can change status and interect with the GitHub issue environment (e.g. add comments) from within Waffle. I think it can provide a nice public window into the project.

Now for people on the project, or anyone who wants to contribute directly, a second icon on the map provides access to the HTML source for each objective chunk:

Option to edit the content of an objective in GitHub

which yes, lands you into scary HTML land

Editing content directly in GitHub

I did a screen recording to demonstrate all these lovely GitHub pieces

https://vimeo.com/172957307

As a System

I’ve given up the idea of asking the public to go to GitHub to suggest resources or ideas. Using a Google Form or the WordPress comments should be more accessible to mortals.

But I remain convinced our production team should work and manage the project in GitHub. I have shown just the Core Certification, what happens to a document-centric approach when we have 3 derivatives?

And here is the nifty part (I think). With the objective content stored in GitHUb as a stub HTML file loaded by ajax on the accordion tabs, when they are updated, the same HTML can flow directly into the WordPress Page structure I set up. If I got super fancy, I might even find a way to sync that into WordPress.

That’s still a semi-conceptual idea, and I am always looking for pats on the back or launched rotten tomatoes on these ideas. Now I have to drag my colleagues into GitHub…

Featured Image: CC0 licensed pixabay image by geralt

 Share this barking on social media

If this kind of stuff has value, please support me by tossing a one time PayPal kibble or monthly on Patreon