Thank you for contributing to CollectionBuilder!
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!
- Email contact: [email protected]
- Main project site
- User Documentation - CB-Docs
- Technical Documentation is found in individual project repositories in the "/docs" folder.
- General project tracking takes place in Issues in individual template repositories, or the CollectionBuilder home repository
- CollectionBuilder Discussions
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.
For questions related to your own project using a CB template, it is best to ask for help in the main CollectionBuilder Discussions form rather than opening an Issue.
Here are some tips:
- How to use GitHub Issues
- 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!).
- Check our documentation resources for solutions and other ways to get in touch.
- You can more informally ask questions and share ideas in the main CollectionBuilder Discussions forum. Discussions is often the best place to post questions about debugging metadata or pages in your own projects (rather than issues with the template code).
CollectionBuilder welcomes Pull Requests from outside contributors. Please provide plenty of detail in the PR so that the project team fully understands your contribution.
- 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
{% if site.example %}{{ site.example }}{% endif %}, not{%if site.example%}{{site.example}}{%endif%}. - 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, sane 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.