ProjectDescription2013 » History » Version 4
Version 3 (Chris Cannam, 2013-08-02 10:08 AM) → Version 4/5 (Chris Cannam, 2013-08-02 10:09 AM)
h1. Project and job description for 2013 reboot
The purpose of the project is to develop a proof-of-concept Reproducible Research Repository (RRR) to associate records of experimental work in the audio and music domain with the software and datasets used and any resulting publications.
This The Repository is intended to be a lightweight source of information about publications and the experimental work they describe, connecting experiments with links to the software versions and datasets used and documentation about how to reproduce the experimental setup.
The intention is to store metadata and descriptive documentation only; software and datasets will be expected to be hosted in other suitable repositories such as code.soundsoftware.ac.uk, Github, institutional repositories, etc, and the RRR will link to these. (It is a Repository of experimental records, not of software or datasets.)
The primary nonfunctional goal is that adding and updating records should be as simple as possible: researchers should be easily able to maintain their own experimental records rather than relying on administrative help.
The project is scheduled to take 5 months for 1 developer, to be structured as follows:
* 3 weeks - Review and document existing work in this field, including an incomplete earlier project within QM, and liaise with data repository team in QM ITS in order to establish whether an existing solution can be applied
* 1 week - Decide and justify whether to use an existing solution or develop a new one
then either (if developing a new solution)
* 2 months - Develop a minimal new system as a proof-of-concept
* 1 month - Deploy to internal test users, revise according to feedback
* 1 month - Document the system and determine the appropriate next steps to take to make a robust public-facing implementation
or (if using an existing one)
* 1 month - Deploy and tailor existing solution
* 1 month - Deploy to internal test users, revise according to feedback
* 1 month - Configure and deploy robust public-facing implementation
* 1 month - Document the system and determine appropriate next steps
The developer must be confident with at least one web development platform, and experienced enough to be able to make the appropriate decisions about technology and infrastructure based on experience with multiple platforms and frameworks.
The purpose of the project is to develop a proof-of-concept Reproducible Research Repository (RRR) to associate records of experimental work in the audio and music domain with the software and datasets used and any resulting publications.
This The Repository is intended to be a lightweight source of information about publications and the experimental work they describe, connecting experiments with links to the software versions and datasets used and documentation about how to reproduce the experimental setup.
The intention is to store metadata and descriptive documentation only; software and datasets will be expected to be hosted in other suitable repositories such as code.soundsoftware.ac.uk, Github, institutional repositories, etc, and the RRR will link to these. (It is a Repository of experimental records, not of software or datasets.)
The primary nonfunctional goal is that adding and updating records should be as simple as possible: researchers should be easily able to maintain their own experimental records rather than relying on administrative help.
The project is scheduled to take 5 months for 1 developer, to be structured as follows:
* 3 weeks - Review and document existing work in this field, including an incomplete earlier project within QM, and liaise with data repository team in QM ITS in order to establish whether an existing solution can be applied
* 1 week - Decide and justify whether to use an existing solution or develop a new one
then either (if developing a new solution)
* 2 months - Develop a minimal new system as a proof-of-concept
* 1 month - Deploy to internal test users, revise according to feedback
* 1 month - Document the system and determine the appropriate next steps to take to make a robust public-facing implementation
or (if using an existing one)
* 1 month - Deploy and tailor existing solution
* 1 month - Deploy to internal test users, revise according to feedback
* 1 month - Configure and deploy robust public-facing implementation
* 1 month - Document the system and determine appropriate next steps
The developer must be confident with at least one web development platform, and experienced enough to be able to make the appropriate decisions about technology and infrastructure based on experience with multiple platforms and frameworks.