Repository of Relevant Resources Intended to be Discoverable, Re-Usable and Continually Accessible.
This repository directory structure is under active development. The current roadmap envisions a Root Level Subdirectory reflecting four large collections clustered around resource type (eg projects and teams, law schools, cities, people, best practices, teaching/training, relevant apps/services/code, etc).
The authoritative location of most or all resources will be elsewhere (some code will be in other repositories, and other resources may exist on websites and other systems of collaborators, partners or external parties. This CommonResources repository is best positioned as a working, operational resource that links to all the key projects, programs, people, places, products, etc. The Git prototcol is well suited for distributed collaboration on active curation, operation and integration of live networked code and hence is well poised to make progress on ensuring best practices, valuable innovationa and other working resources can be discovered, accesssed and even fetched, installed, configured and integrated with relevant systems like course management, open data, and project management services.
An authoritiatve "archived" version of of every key resource created by or arising out of this consortium should also be available in this or an adjacent Repository in the OpenInnovationNetwork. In addition, it is very important to have key resources loaded to a proper long term online archive service that supports the relevant standards, practices and procedures fit to those purposes.
Routinely loading key version of CommonResources to an external archiveis very important not only as a "backup to the backup" but also to enure a reliable, dependable, provable, safe and effective access to the resources over long periods of time and across many different and ever changing contexts. Communities of common interest form coalitions, consortia and other connections for the purpose of sharing information and resources all the time and some may continue for a significant period. However, the mission and purpose of such groups is not the samee as the mandate of an archive and therefore any number of reasonable changes in oerational, stylistic and substantive practices can be expected to make it difficult or impossible for for external parties or later parties to easily discover and rapidly re-use CommonResources. In our case, the Open "Innovation" Network literally has "innovation" as the center of it's mission.
By using an external archive service to house an authoritative copy of key final or key version of important CommonResources it is possible to provide truly cost effective links and real-time programatically addressable end-points for continuously and perpetually stable locations. Arcive.org, operated by the Internet Archive, is the recommended destination for routine loading of the "final" and "major release" versions of OpenInnovationNetwork CommonResources, whether they be works from collaborative projects, from innovation oriented events (like hackathons) and other relevant resources. Ensuring a "copy to the archive" standard operating procedure can be as easy as configuring apprpriate metadata on a link for one-click upload or can be built into the underlying operation of whatever process participants would ordinarily use to share or update CommonResources (eg the same form based or service based uploading process can also trigger an API-enabld upload of the resource to Archive.org with all the relevant metadata, names, descriptions, links, etc intact, mapped and loaded into the relevant Archive.org collection(s) associated with the Open Innovation Network.
This GitHub repository excels at hosting working code that is ready for implementation or production grade deployment. When possible, such code should not only be linked to but in addition a working copy should be forked into the OpenInnovatonNetwork and key top-level documentation and integration assets shoudl be included in this "CommonResources" directory, in accordance with license rights and other expectatons. Especially high value software code that could be appropriate for this Repository could include sets of conifgurations, snippets of code and other integration oriented meta-data, scripts and other light-weight small footprint files. Large footprint, complex or self-contained code bases ordinarily would exist in their own reopositorie. So, items like blocks of javascript, config files or dev-ops automation files that connect combinations of CommonResource applications together and/or integrate CommonResource code with external systems (whether educational such as Moodle, or municipal, such as Socrata, or other systems) would be good fits for inclusion here.
GitHUb is recommended as the authoritative location of an "active, working copy" of files for which engaged communities of contributors actively develop the resource. The versioning capabilities of Git are powerful for determining which version (commit) is referred to in a way that can be accessed as though it were archived. Howver, the data is not necessarily going to be accessible in the same way (or accessible at all) a long time (or even short time) into the future. GitHub is very good, but there are many hard to predict circumstances and situations that can cause data in a repoitory here to become hard to find later. Factors that may complicate or terminate later access including innocent choices to change a repository name, decisions to fork repositories elsewhere or combine contents of previously different repositories, and subsequent disputs among collaborators leading to deletion of repositories from GitHub. Other regular business factors to keep in mind when considering an appropriate level of reliance on currently free, open and accessible CommonResources include unexpected legal contests arising from external third parties about ownership, control, acceptable use and other righs, obligations or other expectatons impacting accessibility, usability, or other assumptons about the CommonResource. The contibitord of resources could be the cause of later businessm, legal or tecnical obsticles to open, free, continued access or use of the CommonResource, whether due to change business model, re-structure legal positions or evolve technical underpinning of the resoure.
Finally, it is necessary to keep in mind that changes by GitHub itself can alter or reverse current assumptions about how suitable a service this is for purposes of this type. GitHub may choose to set in motion, or be forced to react to, any number of business, legal and/or technical shifts in policy, priorities or principles. Consider that a little known prohibition against having too many GitHUb "organizations" under the name of any single user (potentially leading to a unilateral decision by GitHub to render "invisible" or to "delete" the repositories within one or more organizations. Deleting repositories with information assets inside is a serious destruction of private property, whether those assets are contributed by public sector, private sector or other parties. And it could be legal (or "legal enough") under the current terms of service I had this experience first hand and while the GitHub staff have been kind, helpful and awesome as always, the fact remains GitHub is a private company that is at within it's rights to create a wide range of new rule or change any existing rules in a wide array of ways, some of which could disrupt, deflect, derail or destroy regular, dependable operations, high value transactions or mission critical integrations. Ensuring all repositories are frequently synced with local versions in addition to loading every sinle important version of key resources in a valid, well maintained online archive sich as Arcive.org, is critical for prudent, longer term pillars of innovation and larger scale value propositions built upon those sturdy foundations