Over the last year, the Scholars’ Lab has undertaken a project to build a tool for creating interlinked timelines and maps for interpretive expressions of the literary and historical contents of archival collections which we are calling Neatline. When the project was first envisioned, it was seen as a stand-alone tool scholars would use to produce geo-temporal visualizations of textual content. However, as we began the planning process, we thought this effort might not only reach a larger audience, but also contribute back to the larger community effort, if the tools were thought of as a suite of Omeka plugins. This follows a general turn the Scholars’ Lab has taken in how it approaches new projects, from the boutique, or one-off projects of the last decade, toward a more concerted effort to use  frameworks in which we build additional functionality as needed.

Having worked on several open-source projects, I know one the most difficult aspects of this style of code development is building a community of support around the software development effort. Perhaps one of the most engaging of the community efforts I’ve experienced has been in the Rails community with their Bug Mashes as new versions of the framework are being developed. The idea revolves around four general ways in which participants can participate:

• Confirm a bug can be reproduced
• If it cannot be reproduced, try to figure out what information would make it possible to reproduce
• If can be reproduced, add the missing pieces: better instructions, a failing patch, and/or a patch that applies cleanly to the current source
• Bring promising tickets to the attention of the Core team

Generally locations (usually programming shops that use Rails) sponsor a day where community members can gather and participate in the bug mashing, sometimes there’s even pizza and highly-caffeinated drinks. The goal beyond getting some good code written is to get more people introduced to some of the new features, encourage people to talk about the experience, and just have a day to geek out for a good cause.

So here’s the pitch, knowing there’s a concentration of software developers, users, and enthusiasts, could we organize a series of bug mashes that promote community involvement through documentation, patches, blog posts on usage, thoughts, etc. on some projects that are commonly used by digital humanists (not specifically this weekend, but some time in the future)? Chief on my mind lately has been some enhancements to Omeka since several of our current projects are tied to that framework, but are there projects that could benefit from this type of planned community involvement? Are there any perplexing coding issues we could could hack on while at THATCamp?