Project plan process.arts as a service

Process.arts, a grass roots web2.0 open educational environment for sharing day-to-day arts practice and research of staff and students, currently provides a new ‘open learning’ space to the University of the Arts London (UAL) that straddles the institution/educational (formal learning) environment and the social (informal learning) environment.  It creates an ‘experimental’ space for open educational practitioners to develop and define a new language for open edu-social practice without conforming or being influenced by pre-existing academic structures and processes.   The transition of process.arts into an official UAL service will test this model and raise questions as to how institutions successfully support and develop autonomous and independent grassroots innovation without homogenising innovation.

In 2012 UAL began the process of rebuilding its VLE framework, and process.arts was identified as a valuable resource that could fit into the University’s new portfolio of tools; consequently, process.arts is due to be officially introduced as a supported ‘service’ in September 2012.

However, the structure of process.arts does not map onto courses; meta data links user-generated pieces of openly licensed text, image, video and audio content together through individual profiles and subject specific interest groups.  Like many web2.0 environments used for education, process.arts can neither really be described as a repository nor as a VLE. Because of this it provides a novel and alternative VLE environment that encourages and supports rich media experimentation and informal learning, a welcome alternative for many to commercial alternatives.  

Conversion to a full service will provide a firm foundation for long term stability, integration with other systems, support and growth.  The project team is in the process of integrating the current informal agile development approach into a more formal in-house system.  The team are addressing outstanding bugs, monitoring user interface changes and identifying outstanding functionality. There will inevitably be some loss of  agile spontaneity although we aim to retain the overall grass roots participatory feel.

Below is a rough project plan, I'll be adding to this over the next few weeks to develop each section.

1 - 1.00
System Documentation

2 - 1.01
Bugs - document current issues to be fixed and priority
See: http://process.arts.ac.uk/content/high-priority-bug-fix

3 - 1.02
Planned Features - document new features planned for PA
See - http://process.arts.ac.uk/forum/1894

4- 1.03
Functional refinements - document required refinements for PA

5- 1.04
User documentation - Create help files and help section for all areas of user support.

6 - 1.05
Admin documentation - Create a list of admin tasks, what's involved, user questions, support, content and comment moderation etc. 

7 - 2.00
Code review, documentation and recommendations

8 - 3.00
Code fix

9 - 3.01
Migrate to Drupal 7

10 - 3.02
Code fix

11 - 3.03
Refine UI/UX

12 - 4.00
Plan training and support

13 - 5.00
Submit code to repository (live service)

14 - 6.00
Integration and testing

15 - 6.01
Moodle

16 - 6.02
Workflow (Mahara)

17 - 6.03
Filestore (edshare)

18 - 6.04
MyBlogs (Wordpress)

19 - 7.00
Future Development