How to organize tasks for a small team
A response to Oliver Habryka, who had asked how rationalist-community projects might better coordinate the long tail of would-be contributors who show up wanting to help but with no specific assignment in mind. The answer below covers two different scales: how a tight team of fewer than fifteen people can run a weekly task list (drawn from Alyssa’s time on a small Google team), and how the open-source world handles the much larger problem of strangers self-matching to projects via Github-style infrastructure.
On the smaller scale, what we did at Google seemed to work pretty well. As a prerequisite, you need to have: A reasonably sized team; more than one person, but fewer than 15, so it doesn’t get unwieldy; A single core idea to focus around, narrowly enough defined that each person’s contributions support other people’s (eg. “improve Less Wrong’s software” is good, “fix philanthropy” is bad); Team members who can dedicate at least moderate amounts of time, so they don’t try to squeeze things inside twenty minutes’ worth of odd gaps between other tasks; Selectivity in hiring; each incompetent or dilettante is just mildly annoying, but each catastrophic hire can do real damage.
How the system works is: The project is broken down into individual tasks, which are of such a size that they take on the order of hours or days to finish.
The tasks are kept on a spreadsheet, which lists the name, person working on it, start work date, end work date, priority, and so on.
The spreadsheet is readable and editable by the entire team.
As people complete tasks, they check them off the list. As new tasks are thought of, they are prioritized and assigned to the list.
Once a week, a team meeting is held. The team leader goes down the list, selects each task, and asks the person assigned to report on their progress. The spreadsheet is then updated.
Once that’s done, the team leader goes down the new tasks, and asks who on the team wants to be in charge of doing them. If no one volunteers, they can start picking people one at a time, and asking them to take the task.
If a task isn’t finished for three or four weeks, it is marked “will not finish” or broken up into other tasks. That way, cruft doesn’t accumulate in an endless, out-of-date “to do” pile, as with so many other systems.
Between meetings, there is also a team IRC/Slack channel (and ideally in-person interaction), so people can ask questions, report progress, raise red flags, etc.
On a larger scale — ie., when someone shows up, and just has no idea what to do — I think we can learn a lot from the open source software and hacker communities. These communities don’t have formal “matching” systems like eg. medical residencies do — each person’s interests are too complex and too unpredictable for them to be very happy with computer assigned tasks. However, they do have Github (and before that, Sourceforge and Freshmeat), and these websites serve absolutely critical functions. Among those are: They describe what the heck each project does, and who is working on it, in a publicly-visible way. A lot of projects in our spheres don’t even go that far. Of course people can’t find you, if you don’t tell anyone what you’re doing. :)
They automatically create an issue-tracking system for each project. This has a number of functions — it lets people report on potential problems; it lets people pitch new ideas which they’d like to see implemented; it gives interested newbies a convenient list of undone tasks to choose from; and it lets people merge duplicates, so all the different people bringing up common problem X can be merged into a single discussion thread.
They automatically keep track of what’s changed and when (“diffs”), so it’s pretty easy to tell which projects have high activity, which have low activity, and which are just abandoned.
After some searching, there appears to be something called “.impact” (do not name projects like that! it makes them un-Googleable!) which tried to make a start on this . However, it looks like they gave up after about ten minutes; the key description text on what looks like the homepage is light grey italics on a white background , which makes it almost unreadable. To quote Eric Raymond’s HTML Hell Page : “Your color sense is between you and the Gods of Bad Taste, but if you don’t stick to either light text on dark backgrounds or the reverse, you will drive away surfers who like to be able to read without suffering eye-burn.”