Thanks for writing up so much @tdooner! That list of UX problems is extremely helpful to see
The gap seems to be in something that can provide for mapping and growing inter-brigade collaborations. The Civic Commons website back in the early brigade days provided a place for publishing redeployable projects, with lists of redeployments/forks organized underneath. The unique use-case is a shopping/collaboration catalogue between brigades
Current catalogues like CfA’s project showcase and the Civic Tech Field Guide seem focused on cataloging end-deployments. For example, there’s an entry for CodeForPhilly.org:
The entry seems to have been loosely scraped somehow, the “Code” link is to some random github repo that just happened to be linked to on the site somewhere. I’m the maintainer, so I should go ahead and click “Claim Now!” to fix the listing myself:
This is a wordpress plugin for maintaining a local business directory, and we’ve already bumped up against its limitations for the most essential of things: keeping the data up to date. Let alone showing that CodeForPhilly.org is a deployment of Laddr, a rating of how mature Laddr is for redeployment, and that there’s a handful of other deployments of Laddr you can browse through. How would mapping out all the forks/deployments of CourtBot at their various stages fit into this? This catalog is probably helpful for some purposes, but is too noisey, of high-volume low-quality data, and not structured for mapping within the brigade network. I hate to be so critical, but I don’t see a path from here to what we’re missing. Certainly a useful reference in its own right but it’s not going to morph from what it is now into a marketplace for cross-brigade collaboration
I think the space we need would have a couple properties we don’t see here, at the risk of coming into this too strongly opinionated I want to take a crack at painting some concrete parameters for critique:
- Project owners should maintain their own project’s table where it is as easy as possible for them to do themselves: within their own repository. We should start from Code for DC’s extended civic.json spec and extend it further to globalize tagging, categorize repositories as projects/guides/libraries/deployments, document support channels, and to link between deployments and their projects.
- Put brigades in charge of their own curation, using their own systems. No central database of projects that someone outside brigades puts together once. I think the way the CfA API is driven by a community-maintained repo that just has a link to each brigades GitHub org or dynamic projects feed is brilliant and the framework we should build upon.
- The data needs to show up right away, somewhere useful that gives maintainers immediate visibility for their efforts that they can take pride in. The brigade map is a great start. How about showing a news feed of new/updated redeployments? Top charts of redeployed projects?