Project Intake and Matchmaking

There are a number of brigades with teams working on improved processes for project lifecycle and matchmaking new members with projects. A national BAT could provide space to share research, results, and work products.

Brigades with overlapping projects (report others in a reply!):

  • Code for Philly
  • Code for San Fransisco

I learned Code for San Francisco is working on a disaster resilience project that has been on our back burner since 2014. The way it was described to me it sounds almost exactly the same as what we had also envisioned.

I also learned that Code for Boise is rolling out CourtBot… which has been a goal of ours too. AND Code for Boise informed me that Vermont’s court case management software Odyssey is the same as Idaho’s. This brought up that the US only has maybe 8 software packages used for case management … so each state has at least a handful of other states using the same software. If we get a list of the few software packages, we can identify which brigades could work together on CourtBot deployment.

1 Like

Ohhh that’s really interested. What you’re talking about is actually a whole different higher-level idea than what I meant and I realize now I was super vague in throwing this topic up

You’re talking about matching similar projects together across brigades

I was talking about a specific project I’ve seen a few brigades working on of systemizing the intake of new projects and members to assist matching members to projects. Most of it right now looks more like talking about how projects get documented/formalized but it’s within the frame of preparing them for matchmaking.

I think that this might be two separate BATs with the possible intersection that part of starting a project at your local brigade might be searching for contemporary efforts

@nFlourish I just renamed your topic from “Matchmaking BAT” to “Project Intake BAT”

Do you want to start a new topic for your idea?

Please do @nFlourish, we really need both.

Interesting… I’ve been thinking of the matchmaking aspect as separate from the project framework aspect, even though the resulting documentation definitely helps make matchmaking more possible. As a potential BAT idea, I wonder if that might be too large of a scope. As I’m thinking about it, I just realized that it’s because I was thinking of implementing the project framework/documentation portion as gaming skill/talent trees but for project best practices and milestones:

1 Like

You might be right that matchmaking is an additional project, I’ve gotten than sense sometimes too… but I also find it tough to separate as any robust matchmaking services are wholly dependent on what gets collected for project intake, and what gets collected for project intake is mostly getting shaped by what we need to do project matchmaking. Given those two facts I can’t imagine how two split efforts could proceed independently. It might be fair to say that brigades exist to carry out project matchmaking, and automating project intake is our path to automating matchmaking.

I see it as a serial process, it’s going to be hard to do matchmaking if you don’t do proper project intake and project frameworking first. A multi-stage BAT maybe? The BATs are supposed to have a defined end date, which is why I thought the scope would be too large to handle at once. I agree it doesn’t make sense as simultaneous independent efforts.

At Code for Denver we’re working on a Members Portal that will hopefully help us with onboarding and connect folks with projects on an ongoing basis. Members will be able to set up profile pages tagged with their skills & interests, and set up project pages that hold all the relevant resources/links (github repo, issues, mockups, google drive folder, etc) for a project, in one place. We’re exploring using cfapi for bringing in our projects and issues from Github. Still early in design/development, so suggestions are appreciated!

2 Likes

@eemshi that’s awesome! I added your project to the list at Project Frameworks/Guidelines/Checklists/etc

There are a few similar projects you should check out (laddr, connector, beehve, brigadehub). I think only Laddr and Connector are under active development still. Laddr does a lot of what you’re talking about, which I help on. If you want to play with it I can create a free instance for you on our multi-tenant server.

This is something we looked at seriously a year ago. In the end Micah setup some customizations to a Drupal site to let us define projects within that framework. We don’t yet have enough frequently active members to need to track the skills and line them up with projects, although it was originally part of the plan.

If any Brigades are curious about our smaller-scale approach to this let me know.

I’d love to hear more about these disaster resilience projects! We just got approached by the City to do a project on that subject so I’m interested in how similar it is to your and SF’s efforts.

Could you post about it as a new thread under Projects? :smiley:

Great work along these lines: https://connect.democracylab.org/

1 Like

Thanks Chris for the shout out. DemocracyLab is a platform connecting skilled volunteers to technology projects that advance the public good. It has many similarities to Laddr and the work of Code for SF. The platform itself can be seen at https://www.democracylab.org. The projects listed currently are almost all in Seattle. We’re looking to prove our concept there before considering expanding to other geographies.

We did a bunch of interviews last year with project leaders and volunteers. The big insights that we drew were that for project leaders, onboarding new volunteers can be inefficient and the costs often exceed the benefits. An insight from volunteers was that projects are often too disorganized for volunteers to contribute to effectively. We’ve taken these insights into account in the design of our platform, nudging projects to be as transparent and well-organized as possible so that volunteers can dig deeply into a project before reaching out to the project leader. By doing so we believe we’ll reduce the cost of onboarding for both parties resulting in more effective volunteer engagement.

The link Chris provided above includes a diagram describing our long-term product vision, which includes connecting other stakeholders in the civic tech ecosystem to create an efficient marketplace for civic tech.

We also are eating our own dogfood, and have articulated our project’s volunteer needs here: https://www.democracylab.org/index/?section=AboutProject&id=1

I’m happy to discuss this further with anyone who’s interested!

1 Like