[UCLP] Course Development Workflow

[William Chambers]

This is exactly what I always thought. I was beginning to think I was 
mistaken. This really sums it up far better then I ever could have.

William Chambers

On Monday 12 October 2009 11:38:06 pm Elizabeth Krumbach wrote:
> Hi folks,
> 
> There has been some discussion today over course development
> preferences, and I wanted to send out a general email to the list to
> clear up some things. All of the content of this email comes from
> discussions this evening.
> 
> I will start out by saying that the goal of this project has been to
> develop some core material for use in 3 major deployment formats:
> 
>  * Live classes
>  * Moodle
>  * IRC
> 
> As such, we seek to to create course outlines, collect resources and
> put together coursework that could be deployed on these multiple
> formats. To aid in this effort I was brought in from the IRC course
> world, Charles was brought in from the Moodle world and Martin was
> brought in based on his ongoing experience conducting live classes,
> and others on the team have focuses in these areas or a combination of
> them as well.
> 
> The general plan for our workflow, at the most basic, consists of the
>  following:
> 
> A) Collaborative discussion and outlining on the wiki
> B) Further development and fleshing out in bzr+asciidoc
> C) Putting material from B into our 3 major deployment formats - live
> classes, irc, moodle
> 
> Now, the obvious problem with this workflow is that people have
> different expertises and may not have time to devote to learning
> bzr+asciidoc and contribute that way.
> 
> Instead, to draw from an example of my work with the Classroom
> project, we want to allow for someone to give an IRC session from
> material outlined in the wiki, but maybe they don't want to/don't have
> the time to formally put it in asciidoc - they're too busy being a
> brilliant kernel hacker. Similarly we want someone who may want to do
> development in Moodle to develop there if that's what they are most
> comfortable with, and we also want folks to give us notes and tips
> from live classes they give without requiring them to formally put it
> in asciidoc themselves. This is all very valuable stuff, so even if
> they skip step B, it can be our job to collect these great resources
> and put them into asciidoc for use project-wide. This would be the
> path of skipping B, and jumping straight from A to C.
> 
> So if you choose to directly go from A to C, we'll allow it because we
> want to see good material come in and the project grow, but it's not
> the ideal since the material is of limited usefulness to folks using
> the other release formats and will require work from the team to make
> it as useful as possible.
> 
> There will be the following basic responsibilities on the team
> regarding the core workflow:
> 
>  * Wiki maintainers keeping track of who is working on what outlines and
>  formats * bzr+asciidoc experts pruning the core material in B (doing 
some
>  backporting too - if a great course is published in Moodle we want to
>  backport the core of it to asciidoc)
>  * Moodle experts putting the documents from B into Moodle
>  * IRC experts putting the documents from B into a format useful on IRC
>  * Real Life session teachers putting documents from B into a format
> that can be taught offline
>  * Course writers either using the set workflow, or developing
> directly for Moodle, IRC or Live sessions
> 
> Obviously this is the dream land ideal - that the project will be so
> vast that we'll have development happening and backporting and
> everything. In reality I think we'll have some people developing for
> live classes and releasing PDFs, and folks developing in Moodle, and
> people giving IRC sessions - maybe it won't all get back to asciidoc
> and we'll directly pull from each others resources to teach our
> segments. But having goals is nice, and this is the structure we'd
> like to see for maximum usefulness of the core course material.
> 
> We still have details to work out regarding precisely what belongs on
> the wiki, and in asciidoc and how much work we need to put into
> writing courses vs referencing existing reference documentation, but I
> wanted to make the basics clear before diving into all that too
> deeply. Charles is going to work on some of his ideas and give
> examples, and Martin has several great courses already developed in
> bzr that we're going to look at to see what our happy medium is
> regarding reference and rewriting.
>