Skip to content

A join page workflow

Luke Macken caught me for a few minutes last weekend, after he had talked with Greg about skillset capturing. Luke wanted to talk about the join page work that Mo and I lead last year, and how to merge that with the idea of capturing skills of people when they join, then funneling directly to projects and specific tasks.

As it happens, when we did that Join page, we were thinking along very similar lines as to what Luke is looking for now, but being a designer and a content writer trying to get something done, we left the computation up to the joiner. That is, we gave them a list of projects and what skillsets were useful there, and left the figuring out where to go next to the individual joining. Crude, but a step forward. It’s great that the mental work we did back then can help inform a workflow tool now.

Luke is writing that computational part now, to take a skillset from the joiner and compare it with a list of projects and tasks within those projects. I think the best order to proceed is:

  1. Create a new workflow that captures skills, puts them in a database
  2. Use the current information we have in the Join page as a basis for the second part of that comparison
  3. Begin ASAP to use the intersection of those two sets to give back to joiners a specific list of active projects (not yet tasks), with a [details] and [join communications] link.
    1. Details goes to the [[ProjectName/Join]] page on the wiki
    2. Join communications goes, right now, to [[ProjectName/Join#Communications]]
  4. When we have a programmatically generated list of tasks ranked by community voting/karma, insert that into the decision tree as another set to find an intersection with
    1. Find a way to get a meaningful union of the sets of projects and tasks, then use that to intersect with the skills set?

This gets us changes within a few weeks that can make a real difference, while also kicking off a skills database that we can use continuously thereafter.

What website idea is complete without a diagram? Even better, it was scratched out on hotel notepaper while sitting at a pub later the same night as the discussion with Luke. This first pass compresses out the details of the decision matrix at the end:

Diagram shows how a join workflow captures skills and interest, then presents projects and tasks relevant to those skills and interests.