-
Notifications
You must be signed in to change notification settings - Fork 9
Community Principles
- Mirador is a flexible and modern front-end interface for examining and comparing IIIF-exposed images and metadata served from the world's research libraries, museums, and digital repositories implementing the IIIF Standard.
- Mirador can ultimately be successful and sustainable in the long run only if it is an open project; that is, it takes contributions from a community of developers across many institutions to enhance and support it.
- We will work to balance progress on Mirador's codebase with open community discussion and transparent decision making as coequal goals.
- The Mirador source code is available through the Apache 2.0 open source license.
Technical leadership of the project will be through a small group of proven developers who have demonstrated commitment to Mirador’s progress and success (and have commit rights to the source code). Committers must be:
- technically adept
- constructive, positive members of the Mirador/IIIF software community
- committed to producing useful, practical code for the community To become a committer, candidates must be…
- nominated by a current committer
- voted on and approved by a majority of the current committers
- committers may be voted out at any time by a super-majority of the other committers
Committers will have a regular meeting, usually in the form of a conference call, to coordinate development & direction. In addition, they will coordinate publicly over IRC and the relevant mailing lists. Releases will be vetted and controlled by a designated lead or leads. These roles may shift from release to release.
- The users of, interest in, resources, and talent pool of the Mirador and IIIF community will spread far beyond the developers on the committers list, and their institutions.
- The Mirador committers encourage and will facilitate taking code from contributors from many sources. Version control and unit tests will facilitate incorporating and using code from many sources.
- Mirador committers will actively take code contributions from non-committers and incorporate it into the code trunk.
- Working code wins.
- You get what you give.
- All contributed code must have full test coverage before it is committed. For more thorough description and guidance regarding the submission requirements, see the Mirador wiki.
- Tests must be committed at the same time code is.
- All bugs and development tasks will be tracked in GitHub Issues.
- All code must be documented before it’s committed.
The current roadmap and milestones are kept up-to-date through the wiki and issue tracker. Committers tend to be notified of issues as soon as they appear, and review all issues at least weekly. The roadmap is continuously updated with input from the community through the IIIF-Discuss and Mirador-Tech mailing lists, as well as at a bi-weekly conference call with several partners interested in Mirador-related developments.