ProjectDescription2013 » History » Version 1
Chris Cannam, 2013-08-02 10:06 AM
1 | 1 | Chris Cannam | h1. Project and job description for 2013 reboot |
---|---|---|---|
2 | 1 | Chris Cannam | |
3 | 1 | Chris Cannam | The purpose of the project is to develop a proof-of-concept Reproducible |
4 | 1 | Chris Cannam | Research Repository (RRR) to associate records of experimental work in |
5 | 1 | Chris Cannam | the audio and music domain with the software and datasets used and any |
6 | 1 | Chris Cannam | resulting publications. |
7 | 1 | Chris Cannam | |
8 | 1 | Chris Cannam | The Repository is intended to be a lightweight source of information |
9 | 1 | Chris Cannam | about publications and the experimental work they describe, connecting |
10 | 1 | Chris Cannam | experiments with links to the software versions and datasets used and |
11 | 1 | Chris Cannam | documentation about how to reproduce the experimental setup. The |
12 | 1 | Chris Cannam | intention is to store metadata and descriptive documentation only; |
13 | 1 | Chris Cannam | software and datasets will be expected to be hosted in other suitable |
14 | 1 | Chris Cannam | repositories such as code.soundsoftware.ac.uk, Github, institutional |
15 | 1 | Chris Cannam | repositories, etc, and the RRR will link to these. |
16 | 1 | Chris Cannam | |
17 | 1 | Chris Cannam | The project is scheduled to take 5 months for 1 developer, to be |
18 | 1 | Chris Cannam | structured as follows: |
19 | 1 | Chris Cannam | |
20 | 1 | Chris Cannam | 3 weeks - Review and document existing work in this field, and liaise |
21 | 1 | Chris Cannam | with data repository team in QM ITS, in order to establish whether an |
22 | 1 | Chris Cannam | existing solution can be applied |
23 | 1 | Chris Cannam | 1 week - Decide and justify whether to use an existing solution or |
24 | 1 | Chris Cannam | develop a new one |
25 | 1 | Chris Cannam | |
26 | 1 | Chris Cannam | then either (if developing a new solution) |
27 | 1 | Chris Cannam | |
28 | 1 | Chris Cannam | 2 months - Develop a minimal new system as a proof-of-concept |
29 | 1 | Chris Cannam | 1 month - Deploy to internal test users, revise according to feedback |
30 | 1 | Chris Cannam | 1 month - Document the system and determine the appropriate next steps |
31 | 1 | Chris Cannam | to take to make a robust public-facing implementation |
32 | 1 | Chris Cannam | |
33 | 1 | Chris Cannam | or (if using an existing one) |
34 | 1 | Chris Cannam | |
35 | 1 | Chris Cannam | 1 month - Deploy and tailor existing solution |
36 | 1 | Chris Cannam | 1 month - Deploy to internal test users, revise according to feedback |
37 | 1 | Chris Cannam | 1 month - Configure and deploy robust public-facing implementation |
38 | 1 | Chris Cannam | 1 month - Document the system and determine appropriate next steps |
39 | 1 | Chris Cannam | |
40 | 1 | Chris Cannam | The developer must be confident with at least one web development |
41 | 1 | Chris Cannam | platform, and experienced enough to be able to make the appropriate |
42 | 1 | Chris Cannam | decisions about technology and infrastructure based on experience with |
43 | 1 | Chris Cannam | multiple platforms and frameworks. |