We take it as very important to expose your task list, undone and unassigned and everything. That is, if your goal is to do things the open source way, which you can do regardless of what domain you are in. Marketing? Yep. Documentation? Yep.
An example I saw today is in this bug report, where Adam had noticed that some of the content in the Fedora 12 Virtualization Guide (English) was actually for Red Hat Enterprise Linux v5. This, it turns out, is an artifact of the development process. The content was for Enterprise Linux 5 first, then was converted to Fedora 12 content. In the process, the author didn’t have the time to update the screenshots. (Which is fine, release early and release often should be the rule; the screenshots can be updated later, as this process is showing.)
By writing out and exposing all the tasks of a project, such as converting a guide from Enterprise Linux to Fedora, you make it possible for other contributors to catch the 20% that you may not have time for. Even where that 20% is not essential for you to call it complete, there is definite value in that 20% for others to exercise legitimate peripheral participation. In this case, the process of updating the screenshots is only going to take a handful of hours, and at the end, the other contributor is going to be more familiar with Docs process, tools, culture, and that one guide in particular. That is part of growing capacity in the project, helping make others in to experts, too.
As it progresses, Adam is interested in helping finish this part of the guide, and Eric gave him some direct tips on getting the work done, all recorded in the bug ticket. Now it can be reassigned to Adam, and he can use the usual resources to find answers and get the updated guide published.
The challenge is, no task ticket tracking system is going to expose all the details to the granular level. The screenshots might have been one on a task list somewhere, but there is a social element to all this. For example, this is why we blog about what we are stuck on as much as writing about what is going well. It’s like the easyfix idea, not everything everywhere is going to get tagged with that, but enough are to make it easier for new people to move from participant to contributor.
Good Stuff! I’ll be forwarding a link to this over to the RIT kids. It might help them to see FOSS dev from other perspectives.
Excellent post, great story, perfect showcase!
Is this along the lines of the raptor-bus anecdote ?
Agreed, there is an interrelationship between an open task list, the ability to grow capacity for a project, and how it protects a project when a key person is eaten by a raptor.
There is video of Max and I discussing that analogy, just waiting for the chance to get it into the edit queue. “Get hit by a raptor, I mean, eaten by a bus.”
I’m envisioning “My project is raptor-proof!” badges…
Seriously though, that’s probably a thought experiment everyone should be going through at least once per release cycle. It’s the type of thing you never need… until you really, REALLY need it yesterday.