What Tools Have Been Used (and re-used)?

[mgifford]

I know that Drupal & Joomla have both been used to run these consultations. Has the code been shared so that other government departments can continue to leverage it? If so have other departments looked at the earlier results and looked for ways to improve the user interface? If two slightly different tools have been used, has their effectiveness been compared?

There are also other tools and proprietary tools that have been used. I would be interested in seeing a list of the types of web tools that have been used for citizen engagement.

There must be a list somewhere with the technology behind the consultations.

[chrismajewski]

Will @sylus wrote the consultation platform for the Open Government Secretariat (OGS) in Drupal but these platforms are almost always custom. They are a solution for the funder's current issue or their description of the problem.

The closest thing I can think of that pre-exists to the requirements Laura is currently defining (#4) would be a CRM where your policy is the product. Sort of a "rate this site" form where we give the public access to search and add to the results.

This seems to be a new category of product that exceeds the current form of collaborative commentary found in forms or under youtube videos without all the computer science requirements of absolute freedom to propose non-destructive (and non-collisionary) change. It looks like we are trying to define something that sits between Git and Google Docs, a tangible gap in the collaborative toolbox.

[mgifford]

Hey @chrismajewski - Will's done some amazing work on creating a distribution for Drupal in government https://www.drupal.org/project/wetkit he was able to build in the wet-boew framework and ensure that it meets the requirements of WCAG 2.0 AA. You start from a distribution and then you customize as needed, knowing that the basic elements are taken care of.

He's also responsible for migrating over 160k pages of data over to this open-source platform. Really puts the Adobe effort to shame as they've just migrated just over 10k at this point - sorry for the diversion.

Although there are always custom elements, departments shouldn't be starting from scratch. Assuming that consultations are going to be something that governments are going to have to get good at (over the next 4-8 years) let's find a way to learn from them. We should know what tools folks are using and discourage people from re-inventing the wheel. Even proprietary code should be purchased in a way that allows it to be shared and re-used within the public sector. There is an opportunity to iterate & repeat, so that learning can happen.

#4 is pretty fresh, so haven't looked at that yet.

I think you're proposing something between GitHub & GoogleDocs. I'd love to see that. I'm not sure it exists at this time and figure we should probably stick with GitHub for now. I suppose one could customize https://about.gitlab.com/ but I'd prefer to use a consultation method that we know works rather than invent a new one.

[chrismajewski]

I work with Will every day, I can throw a sufficiently crumpled page of A4 and hit him at his desk. I'm also a WET contributor, to a lesser extent, and the one who invited him to this GitHub org. It's not Will, it's the requirements. We really do need to get that right or we are repeating the same mistake but that's beside the point of your issue/thread, that can be found in #4.

What I meant by that is much of what has been built has an inherent bias to the source issue. We'll need to keep that in mind when considering anything pre-existing.

Also, I did mean Git which sits under those platforms. GitHub has some nice pull request workflow but I do think GitLab is superior on the reporter/public side. I've migrated our whole shop's client side management to it and I'm presently tinkering with it's API to automate most of the reporting.

I was more picturing a Google Doc's style document UI with seamless Git integration offering direct editing with Git collision mitigation, branching and revision control. GitLab isn't a horrible place to start if we end-up there by requirements, at the very least it's open source and adopted by SSC in the form of a GC instance of it.

I've seen Git, using publish scripts, mange project file contribution (project plans, requirement definition, change management policy) but I've never seen it done for something quite like this. Nobody walked in without the support required to understand or at least manage Git submissions.

Revision control is still something nearly exclusively for the techs, at least in a mass collaboration platform. Major online providers are still having issues delivering on this technology.

Not locked or leaning into anything till I know where we are going. I just start from the technical side that's figured out collaborative revision control.

[mgifford]

Don't be throwing paper at Will. :)

Lots of advantages to tools like GitLab. Too easy to confuse Git & GitHub I find. So many folks mess it up. One big disadvantage of GitLab is that it can be private and doesn't do as much to break government silos.

Ya, I wouldn't want to expose your random policy wonk to Git... GitHub is pretty good, but even that freaks folks out.

I know I've seen GitHub used for forming policy (edits & pull requests) & collecting input (forums). Just not sure if I can still find it.

[chrismajewski]

To GitLab, it's not unheard of to fork a project intended to do one thing and bend it to do something else.

All the benefits of GitLab, all the public side openness of a collaborative document space? Sounds really interesting.

I see a PHD in that work, maybe external funding (in time) is possible?

[patcon]

I agree that what you two are talking about doesn't exist, but if it were to come into existence, I think it would make sense to start building off of (or at least learning from the methods of) prose.io. Here's the source. It's basically aspiring to be a WYSIWYG editor for git repos -- it makes all changes via GitHub API, with 99% of the magic is in the client-side JS in the browser and 1% in a very slim auth gateway that they wrote to do the bare minimum for authentication with GitHub.

A few projects that I know of have copied their modus operandus:

• EditData: A CSV editor backed by GitHub API.
• JKAN: A data portal backed by GitHub API & Jekyll.

Both allow on-site/in-page edits of GitHub repos (without even knowing edits are happening on GitHub), made possible via the auth gateway. Pretty interesting possibilities.

EDIT: @tristen is speaking at Civic Tech Toronto on Tues, Feb 7. He'll be repping Mapbox, but he was involved in the early versions of Prose (if I'm not mistaken). Just putting it out there in case either of you wanted a chance to pick his brain at a #civictechy venue ;)

[MaryBethBaker]

Archiving this issue.