Content Packages

[jmatsushita]

Software libraries and projects both have:

• a collaborative lifecycle using git, where contributions are progressively integrated in a common repository
• a release lifecycle where a repo at a particular moment is made available to a community, usually with a version number possibly on a package repository.

It seems to make sense to also think about packaging content units when they are part of the same release cycle, and would benefit from being tagged with a version number, for instance to update clients that use the content package. This seems that it would be a building block of a technical approach to content reuse, where content packages would be collaboratively maintained and reusable.

I think there's a lot to learn from OFK's Data Packages which recently hit 1.0.

I've done some basic implementation piggy backing on the npm registry for safetag with:

• A docsmith feature which automates npm to download the latest package.
• A content.yml description which contains content package dependencies for a particular project.
• A first content package which contains its content and its instructions for it to be built, published on the npm registry.

Some open questions and directions of work are:

• Wrapping up the package release in a high level interface.
• Think about light-weight forkability and three way merge in the context of packages.
• Transclusion between content packages.
• Look into how this fits with content reuse