I'm Soren Scott, a research coder (not a student!) on the BCube Semantics project, and here today to give a brief update on my FUNding Friday project, ESIP:Funded. The idea for this work came out of a conversation during in the first session of the Semantic Web (SemWeb) cluster at the 2015 ESIP Summer Meeting:
What if someone has a code repository where the work was at least in part supported by ESIP but you didn't want to host it under the ESIPfed Github organization?
While I could talk about pros and cons of hosting a repository under the ESIPFed organization (and this is a community question that I'll pose to the larger group), it's pretty safe to assume that there's always going to be repositories hosted elsewhere. So we're back to the original visibility/branding question, to which my response is “let's badge it!”
Figure 1: A real-world example of badging from the Luigi repository.
Within the Github community, badges are small graphic elements that give a very quick indication of things like code version, build status or code coverage. These are located at the top of the repository's README. Most of the time, these are pretty technical bits of information but we can take advantage of the concept to answer our question. Rather than code coverage, we can add an ESIP badge for the Semantic Web cluster or to indicate that this code came from a FUNding Friday award. So, with one line of markdown, we can show a relationship to ESIP in our own repositories without requiring hosting under the ESIPFed organization.
I've focused on three concepts to highlight – things receiving direct ESIP support (this FUNding Friday project or Toolmatch), things that have come out of membership in ESIP (a collaboration fostered through some cluster participation, for example) and things related to a cluster or working group. These are not set in stone and I am quite happy to revise the API to reflect the community's wishes on this. Feel free to make an issue on Github or drop me a line. And so with a nod to *Norberta, let's put a badge on it!
Using the ESIP Badges
The badge design uses the de facto standard out of the shields.io project. From our earlier example, we can see that often these READMEs contain multiple badges so using this design pattern keeps everything consistent and not visually jarring.
In addition to the three types of badges, the current API gives you two more options – one of the three shields styles and one to use the ESIP logo instead of text.
Figure 2: (top) Badges with the logo option. (bottom) Badges with the text option.
Using the badges, once you've decided which badge and which options fit your particular repository, is as easy as adding a line to your markdown:
Commit your changes and you are good to go.
For more info, see the API's documentation. All of the available badge options are listed here. I would note, as well, that these can be used in other code-hosting platforms that support Markdown rendering and in Jupyter/IPython Notebooks.
\* Norberta was our chatty bird gatecrasher in Merril at the ESIP Summer Meeting.