[UCLP] Course Development Workflow

[Vantrax]

That is an excellent summary of what we discussed. Much better that I could
have put it.
-Matthew Lye

You can do anything you set your mind to when you have vision,
determination, and and endless supply of expendable labor.
<No tree's were harmed during this transmission. However, a great number of
electrons were terribly inconvenienced>


On Tue, Oct 13, 2009 at 1:38 PM, Elizabeth Krumbach <lyz at ubuntu.com> 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.
>
> --
> Elizabeth Krumbach // Lyz // pleia2
> http://www.princessleia.com
>
> --
> Ubuntu-Learning mailing list
> Ubuntu-Learning at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-learning
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/ubuntu-learning/attachments/20091013/22840a78/attachment.htm