These are the notes from the workshop held in the Kineo Brighton office on 19th and 20th December 2013.

Overall, the workshop was very productive and we covered a lot of ground. It was great to spend time face-to-face and for some of us to meet in person for the first time. Thank you the guys from Learning Pool for travelling over.

Attendees:

• Mark Lynch
• Ryan Adams
• Tony Finlay
• Paul Welch
• Daryl Hedley
• Kev Adsett
• Sven Laux

Preparing for first official release of the Adapt Framework:

We went through the non-coding tasks, which need to be taken care of to ensure a successful Adapt Framework launch 

Adapt Framework version 1.0 – decisions and tasks:

• Coding ends 20^th January 2014
• Thorough testing up until 27^th January 2014
• Official planned release date: 27^th January 2014
• Community site configuration has been changed to enable guests to read forum posts.
• Community site to be updated prior to 20^th Jan. (Action: Sven)
  This includes a review of all content pages, the creation of a landing page for documentation. The landing page will include links to essential reading, getting started instructions for developers and links to relevant documentation on Github.
• Create public backlog (Action: Mark)
  We now have the scope of the first release of the Adapt Framework and, by proxy, the roadmap items. We have agreed to add the user stories into a public backlog (using Github issues/milestones). Github will contain the detailed tasks and descriptions, while the planning and work allocation for collaborators will continue to be done via Redmine. The specific task is to add the user stories to Github.
• Tidy up Github (Action: Ryan)
  We have generated several pages of documentation. These are not coherent at this point and we agreed to review Github and ‘tidy it up’. This includes several pages, wiki pages and .md files. It also includes reconfiguring access permissions (to avoid having too many people with direct push permissions) and writing up a ‘expected standards for inclusion’ page. The task excludes making any changes to the repositories.
• Adapt CLI to generate test course (Action: Daryl)
  We agreed that it is important for the Adapt command line interface to generate a populated test course (akin to the demo), so that developers can generate content to examine and play with. We want to include this in the first release so that the barrier to entry for developers is as low as possible.
• Pre Learning Technologies Marketing activity (Action: Sven)
  Seeing as we now have the demo and a clear idea about deliverables, we would like to encourage the organisations involved to market Adapt ahead of the UK Learning Technologies conference in January. With the first release, our aim is to get to as many developers as possible and prompt them to start using the Adapt Framework. The task is to engage with the various marketing departments.

Adapt Framework first (MVP) release:

• We worked through and agreed the requirements for the first release of the Adapt Framework. All proposed requirements have been ‘MoSCoW’ rated and documented in the attached file.
• Task: Complete user stories from requirements and add to public backlog in Github (Action: Mark; same as above)
• Task: Complete resource estimates and sprint planning in Redmine until first release (Action: Daryl; with Mark’s help)
• Task: Define Adapt Framework roadmap by grouping requirements not met in Framework release 1.0 (Action: tbc)

Adapt Authoring tool:

• As part of the workshop, we focused on the Adapt Authoring tool and discussed requirements and release schedules. We agreed that it is most important to define the following two releases. Our guiding principle for tackling the releases is that we value stable, working software over volume and speed of delivery of features.
• Release 0.1:
  With this release we’re delivering a ‘skeleton’ authoring tool, which still requires developer engagement. This is therefore not suitable for our ultimate non-technical target audience. Once we have this release in place, we will recruit a set of contributors, who can help guide us towards a suitable first version for non-technical end users. The contributors we seek would be interested in helping shape the project and able to test, review, document and offer opinion on features, design etc.
• Release 1.0:
  With release 1.0, we will deliver a fully functioning authoring tool, which is aimed at non-technical end users. We will package a feature set, which differentiates the tool in the marketplace and we drive for achieving a viable replacement of other tools our target audience may be using at the time of release. At this point, we still expect to have a long list of roadmap items and be quite far off a market leading position.
• In light of the above, we concentrated on reviewing and MoSCoW rating the proposed set of requirements. We managed to get around half way through the mindmap. The interim result can be seen in the attached document.
• The next step is to continue with and complete the exercise of reviewing the requirements rating. We will pick this up via teleconferences in the new year.