Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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 branch(s) 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 branch(s) branches will be merged into the corresponding master branches(s)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.)

It is expected that contributions will be 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.

Reviewing code for acceptance