I've been chatting with folks about this idea for a while, and it's now time to write it up and get it moving. Summary version: as part of/in tandem with the Git migration, I want to create a set of git-for-Drupal training tools. There's a particular structure I have in mind for how these tools should work:
- First, we define our different target users/audience. For git, some the obvious groupings are "authors & maintainers" and "patch contributors"
- Then, we break down what's really necessary for each of these target groups into discrete learning objectives - skillsets or knowledge bases that we want the trainee to get a handle on. Ideally the learning objectives should overlap as much as possible between the different target groups.
- Finally, we build targeted educational tools geared towards achieving a particular learning objective. That can mean written documentation, cheat sheets, images, short videos/screencasts, etc.
These pieces, and the process of creating them, constitute the core building blocks of a reusable, shareable curriculum. With these pieces in place, individual trainers can pick and choose from the set of available tools to create a training course that's most pertinent to their specific case: maybe they're giving a session at a Drupalcon or Drupalcamp. Maybe they're giving a five-minute "teach just this one thing" lightning session. Maybe they're doing a whole-day git/Drupal training at their workplace. Whatever that trainer's need is, this set of tools should help her/him to identify the crucial things that the audience needs to hear, and provide ready-to-go tools that help make that happen.
As with any open source process, I'd hope to see people contribute back. I'd hope that would happen by way of the three bullet points above getting rehashed, but I'd also hope that folks would contribute back whole training programs they've put together, as well. Training, after all, is really one of those things where the whole is greater than the sum of its parts.
I'm hoping we can get this process moving quickly enough that what we develop can form the basis of a training program we run at Drupalcon CPH (http://cph2010.drupal.org/sessions/git-fundamentals ); ideally, we'll also use it to run several smaller BoFs there as an alternative way to get people trained up. Getting this process moving, though, is going to be heavily dependent on the User Stories discussions.
I'd like to use this thread to discuss the viability of the idea in general, and also to come up with a list of people who'd be interested in really driving this process. Once we collect that group of people together, I'll organize a chat on IRC and/or over Skype to really get things moving. I know there are a lot of people who are excited about this, who already train git-for-drupal, etc., so I'm really hoping to hear from y'all :)
Comments
Open curriculum working group
It's hard to keep track of whose talking to who, but what you're describing is one of the larger goals of the Open Curriculum working group that's been collaborating in #drupal-dojo on a (semi) regular basis since DrupalConSF. Detailed summary/roadmap forthcoming, this post here may provide an overview and how some folks are already using GIT.
I'm thinking we could help push this forward!
Gus Austin
It may well be. Probably is,
It may well be. Probably is, really :) This is just what I came up with to tackle the specific, time-sensitive problem of getting our ducks in a row for the migration. I'd be happy to fold this effort in elsewhere if that's what makes the most sense. I'll ping you in IRC so we can talk details.
Doc's for the rest of us...
Don't know if this has been considered or discussed or matters but here goes. I'm new to contributing to drupal and will be learning Git from a complete noobs perspective. I have never used CVS. I'm hoping that the learning docs will take this into account. I hope that they will not all be written/presented in a way that requires me to understand how CVS works(worked) in order to understand how to use git. Hopefully it's possible that their be docs, tut's and learning tools that are aimed at people who could benefit from the comparison explanation but also maybe a track for those who are brand new.
Excellent clarifying question
Excellent clarifying question - and no, in my thinking, the focus will be on training the stuff you have to do from a base of zero knowledge, not from a CVS background. Any docs that map CVS -> git will be separate.
down for meeting
i'm really into this.
my interests: championing new developers / 'aspiring project maintainers' as well as finding every opportunity to make learning git + the sharing process friendly & fun. i have not maintained modules, but I want to in the future. I am grumpy about the CVS application process and have given up and am waiting for Git. So want to get this going. Huge fan of GitHub.
i'm teaching an online class (in a drupal learning collaborative) in the next few weeks - git class. so, in a few weeks I will have new strong opinions that I can't yet predict.
i'm interested in participating in a git installfest during copenhagen (but not in minneapolis, as i am not going to copenhagen.)
perhaps try out some of these materials & see what happens.
chatted with sdboyer yesterday, and it sounded like we are going to need to find a good place to have our discussions & host our materials. Is there already somewhere in the dojo-sphere?
looking forward to the call, whenever it happens.
count me in
I've had some talks with Lynn Bender in Austin Texas about his ideas on open sourced curriculum and think he might be interested in helping out here as well. I think he may already be involved in the aforementioned group by @gusaus.
I've done a lot of teaching of Git internally with the Lullabot crew and of other friends. I've also written a few articles, so I'm certainly willing to help out here as well. We've been talking about coming up with a curriculum for Git ourselves to teach at our workshops as part of our systems administration classes, so this would certainly be of great interest to us to participate in.
As for intended audience, has this been hashed out before? I know there was something I read somewhere about 'CVS for Themers' so I'm wondering if this is something others have already thought out, segmenting our community to teach from particular perspectives. This is probably the most important aspect of the proposal as the 'what to teach' aspect will be geared towards each.
Traditionally, I see the community segments being:
1. I'm a complete newb trying to build a site.
2. I've graduated from complete newb and define myself as
2a. a jack of all trades.
2b. a themer.
2c. a developer.
3. I've been involved for so long that I do what needs to be done.
4. I only work on core things.
Forgive me if I'm forgetting any segments. But these would give us a good basis I think. It can probably further be simplified as:
1. newb
2. themer (non-contributor)
3. developer (non-contributor)
4. contributor of themes
5. contributor of modules
6. core contributor
Maybe even further - combining 2 and 4, 3 and 5:
1. newb
2. themer (contributor or consumer)
3. module developer (contributor or consumer)
4. core contributor
Then we come up with questions each role might have related to Git. Namely, "How does d.o's move to Git effect what I do on a daily/weekly basis?". Craft this question to each particular role and then answer it. With that answer, give all pertinent background context that each should probably know.
I guess each role basically has a 'push' and 'pull' aspect to it ... 'push' being 'contributor' and 'pull' being 'consumer' - both pertinent aspects of what we all do. We all 'pull', but only some of us 'push'... so it's relevant for each role that they learn how to do both.
Some preliminary questions:
- how do I get core and contrib code with Git?
- how do I contribute core and contrib code with Git?
More specific:
- how do I contribute a theme with Git?
- how do I contribute a module with Git?
- how do I work with my issue queues and patches with Git?
- how do I contribute a patch to core with Git?
- how do I contribute a patch to a contrib theme/module with Git?
roles
Here are also some very good roles defined: http://groups.drupal.org/node/67763
Task based > Role based, methinks
I think lots of people have a hard time classifying what "role" they fit into, especially when there are so many. OTOH, they all know what specific tasks they're trying to accomplish (I want to grab a copy of a theme from version control, I want to create a new module on drupal.org, ...), and many of these tasks span "categories" of people. Single-sourced content ftw; writing the same instructions multiple times with slightly different headers/footers sounds like a recipe for frustration (unless I'm misunderstanding the intent).
I do definitely support off-shoot pages though that give additional context if the reader needs it. For example:
"This page discusses how to do Example Task. It assumes knowledge of blah and blee.
// Instructions for how to do Example Task....
"
I agree entirely that, when
I agree entirely that, when it comes to writing the semi-static documentation on d.o, that the most immediately accessible way to break it down is by task. Any role-based divisions we create are inherently artificial, and require folks to more or less see inside our heads to know which part of the documentation they need to go to. Silly.
So let me clarify: the grouping/roles classifications I talked about are not for the self-navigating handbook documentation (or at least, shouldn't be the primary organizing element). I like the list sirkitree linked to (http://groups.drupal.org/node/67763), though I don't think all of those are necessarily going to be valuable here.
Yup, totally agree
People are smart enough to figure out where they should jump in if you are clear on pre-requisite knowledge for each task and provide appropriate context when needed.
Task based is solid and simple and assumes the reader is competent.
Role based is nebulous as your are always "guessing" what role someone is or where they are coming from.
When it comes to interacting
When it comes to interacting with git, I think this list:
is close. Lemme reorganize a bit:
So the ideas here being, a) I don't think that there's enough difference between what a theme and a module maintainer need to do to justify listing them separately, but b) I do think the differences between an author/maintainer and a contributor justify a separate classification as they really are a different skillset. c) that doing core contributions is different enough that we should probably teach a couple extra things, and d) that newbs need to be oriented to git in general, and maybe to the different roles folks often play as they appear in this list (so they'll know when they need to pick up more skills).
In terms of learning objectives, that would look something like:
newb
contributor
contrib author/maintainer
core contributor
That set, I think, would give us plenty to work from in terms of developing curriculum tools. Additionally, to address webchick's comment about tasks > roles, each of those learning objectives probably WOULD work well in a "How do I..."-organized handbook documentation structure.
And just to reiterate, the
And just to reiterate, the value of roles here is as an internal organizational tool for us, documentors/trainers, to ensure we're covering all our bases and to help new trainers think about what ought to go into the training sessions they're putting together. They're not so much about public presentation, let alone an organizational structure for static documentation.
getting to the next level
since git is the secret magical ingredient in becoming an open source contributor it would be great to include step about 'how to move up to the next level'
especially for the beginners new to the drupal process.
A concrete example i can think of is regarding documentation:
Under beginner, it would say ' how to become more of a contributor' - and would link to:
* materials about using git in documentation/doc sprints
* using git to work on novice issues in the issue queue.
In my mind this is a small, but huge, suggestion because the idea of being able to volunteer with something simple is a realistic & it works in building our community.
Practically: the tips would be listed under 'contributor' as a 'use git to add documentation' or something like that.
sdboyer: i like that you have 'contributor' as the role title and merge module developer/themer into one -- since the technical part is so similar. and it is more flexible in the long run.
'contrib contributor': could link to information about becoming a project leader
where to write?
I like the structure, I I think we should start soon an correct it in the road, since we could get in a while 1 loop.
So, where is the right place to actually start?
The best way to start
The best way to start developing material is to have an immediate need.
Chacha is working on a group-learning project which, among many other things, includes teaching participants how to use git. Join the group over there, especially if you know git and want to experience how to teach it.
http://garden.localbiology.org/git
Before spending too long on the design of materials and outlining the content, I'd say it would be better to tuck in an attempt to teach it first, and keep notes as you're going. This will give you a better idea of: "What does this person need to know before I introduce X concept? What background experience or info would they need before they undertake this task?"
In terms of the materials and re-usability, think in terms of 30 minute sessions with several exercises that build on each other, towards mastering a task. This is assuming you want to make materials for re-use in community drupal meet-ups. The steps need to be clear as to be good for group and self-study, we can't assume people in the community know this stuff either.
People are goal oriented. The roles are not as important as what people's prior experience is, and what their aims are.
The roles sdboyer - posed make sense from the user-goals, and their prior experience.
I grouped in contributor and core contributor together. I don't see a clear line between those. Might be good to start off with patches to Core, and then introduce how to submit patches to contrib modules.