Link Search Menu Expand Document

CollectionBuilder

Contribute to CollectionBuilder

Outside contributors are welcome and encouraged to help develop CollectionBuilder templates and documentation on GitHub.

CollectionBuilder prioritizes pragmatic, sustainable, and simplified approaches to infrastructure to ensure the tool is “do-able” and approachable for digital knowledge workers in libraries and museums, empowering them to take control of their web systems. The core team is not full time developers–we are librarians. Thus, we are focused on creating a supportive, inclusive community with low barriers to contributing (please see our Code of Conduct).

Honestly, we do a lot of stuff the slow/old/inefficient/wrong way… but we make it work and invite you to learn/teach with us!

Project resources

  • Most development happens in our main repository CollectionBuilder-CSV. Other templates and Built Ons pull from the CB-CSV base.
  • Technical Documentation is found in individual project repositories in the “/docs” folder.
  • Extensive comments can be found at the top of most template files and inline in code.
  • General project tracking takes place in Issues in individual template repositories, or the CollectionBuilder home repository

Issues

Since this is a relatively small project, we are informal in using GitHub Issues and welcome you to open one to get in touch. Issues should be opened in the repository of the specific template you are using for bug reports, feature ideas, and requests for missing documentation. The team also uses Issues for project management related to the CollectionBuilder project.

Here are some tips:

  • Please focus on clear communication, providing plenty of detail and links so that we can understand the bug or proposal.
  • Search the Issues to see if a related report has already been opened (if so add a comment or reaction!).
  • You can more informally ask questions and share ideas in the main CollectionBuilder Discussions forum.

Pull Requests

CollectionBuilder welcomes Pull Requests from outside contributors. Please provide plenty of detail in the PR so that the project team fully understands your contribution.

Conventions

  • Include lots of inline comments documenting code! The entire CollectionBuilder project has a educational outlook.
  • Keep code structure relatively simple. The templates are intended to be comprehensible for digital librarians and DH practitioners to use and modify, not necessarily fully optimized solutions.
  • Include spaces for readability. For example, in Liquid , not.
  • To improve readability, avoid excess white space and random indentations.
  • Indent using spaces. HTML, JS, CSS and related files should be indented using 4 spaces. YAML with 2 spaces.
  • Use ; in metadata to denote multi-valued fields.
  • New features should be progressive–adding features, while maintaining backwards compatibility with existing data setups. If possible, sensible defaults should be set in Liquid and JS, so that projects lacking updated config variables will still function.
  • Main branch should be code that is ready to go. Use feature branches for development and provide meaningful commit messages.