Contributing to DPLA Projects

Which Projects to Develop

We have a number of projects, some of which are under development and can benefit from work, and some of which are considered legacy and are not worth investments in time and energy by outside parties.

As of June, 2017, the projects on GitHub that are current are:

• Ingestion 3 (but it's in a very early stage of development and we may not have the ability to coordinate major work with outside parties just yet).
• Automation
• Usage Dataset Collector
• thumbp
• sitemap
• introapi
• Find Your Public Library

Projects that are in legacy support mode, which should not be developed further except for bugfixes or maintenance. In most cases, we can't consider feature enhancements.

• Ingestion 1
• Krikri
• krikri-spec
• Heidrun
• heidrun-mappings
• Audumbla
• Frontend
• Platform
• Primary Source Sets
• Exhibitions
• Anything else you see under https://github.com/dpla not mentioned above is being kept for archival purposes only.

That said, all of our publicly-available code on GitHub is licensed under very permissive licenses that permit you to run with it and use it for your purposes. Be our guest! It's just a question of whether we can accept contributions that are merged back into our repositories, and whether we are able to put energy towards code reviews and evaluation of new pull requests; and also whether you want to use some of this older code that does not represent where we're headed these days with our current efforts.

Workflow and Style guidelines

Please observe the following guidelines:

• Read about our Branching and Release Model. You need to be able to determine if our repository uses GitFlow or OneFlow.
• Write tests for your contributions.
• Document methods you add using doc comments.
• Follow the included style guidelines.
• Use well-formed commit messages. Highlights from the aforementioned resource:
  • Use the imperative voice
  • Limit subject line width to 50 characters ideally, 72 characters maximum
  • Explain what and why
• Fork our repository, create a topic branch, and submit a GitHub pull request targeting either the master or develop branch of our repository, depending on whether our repository uses GitFlow or OneFlow.

Evaluating External Libraries

When deciding whether or not a library is a good fit for a project, we will evaluate its inclusion based partly on these questions:

1. How well documented is the library?
2. How good is the test coverage?
3. How well maintained is the library?
4. Does the library meet our specific needs?
5. Is the library modular?  Can you easy apply the pieces you need within your system?  Or is the library monolithic? Does it draw in more dependencies than you need?
6. Does the library have any code smells, which is to say, does reading it cause any surprises to those familiar with its language, or does it go against established best practices for that language?

Licensing and Copyright

Most of our projects since 2014 are released under the MIT license, and other projects are released under compatible licenses (including Apache 2.0 and the Unlicense). We are interested to learn about restrictions that hinder external contributions by non-DPLA staff. Please contact us at tech@dp.la if you have observations you'd like to share.