This is a rough, early draft of the CollectionSpace Community Contribution process: the process by which CollectionSpace community members can contribute work that advances the core project, customizes it for use in various domains, and the like.
This draft is based on rough notes and a whiteboard sketch from the CollectionSpace Developer/Deployer meeting of February 8-10, 2012. It is intended for review, discussion and refinement.
Examples of community contributions
Examples of community contributions may include:
- Source code additions or modifications, in Java (Application and UI layers) or JavaScript (UI layer)
- Example: adding new procedures, such as rights management, condition checking, valuation
- Example: adding new capabilities to the user interface, such as the ability to display text addresses or lat/long pairs on a map, or to validate data entry against external web services
- Schema extensions
- Example: adding new fields widely used within a specific domain, like art history or the life sciences, to existing object or procedural records
- Modifications to HTML templates and CSS stylesheets
- Configuration additions or modifications, such as changes to configuration files in any of CollectionSpace's layers
- Data import tools, including ETL templates and import scripts
- Data cleanup scripts
- Utility scripts
- Lists of authority terms
- Lists of vocabulary terms
- Translations into different languages (e.g. translated 'message bundle' files for localizing text labels)
- Documentation
- Notes on best practices
- Wireframes (drawings of user interface screens and sequences)
The mechanics of contributing
CollectionSpace has recently moved its source code into public repositories on GitHub. There are git repositories there for each of CollectionSpace's three layers:
- application
- services
- ui
For most code and configuration contributions you may wish to make, we encourage you to use GitHub to fork ('clone') these repositories, and then use git to create a local feature branch containing your changes, in each relevant layer. The project's developers will then create corresponding feature branches in the relevant layers in the main CollectionSpace repository, to which you can issue pull requests. When contributions are approved, the changes in the feature branches will be merged into the corresponding master brancheses, then the feature branches will be retired (removed).
If you have made your configuration changes in the CollectionSpace mini-build, you can first copy your added or changed files from the mini-build into your local feature branches for the relevant layer(s). (A future version of the mini-build may offer tools to make this more convenient.)
If you are contributing files that don't need to live within the CollectionSpace source code trees, such as import scripts, vocabulary term lists, documentation, or wireframes, you can make these available in any convenient manner, such as on your own website.
The most useful contributions, which are most likely to be accepted into the project, or else, to be most easily adopted by other institutions within the community, are contributions limited to a single distinct feature, such as a new procedure, a new user interface function, or new and improved method of importing data. A mix of multiple customizations for your museum, while useful in its own right as an example, and itself worthy of sharing, may be somewhat more difficult to incorporate into the project or to be adopted by others.