GitHub for Journalism — What WordPress Post Forking could do to Editorial Workflows
Wired Magazine recently took a turn for the meta. In addition to publishing their recent story featuring the popular version control site.GitHub on Wired.com as they would normally, they also published it on GitHub itself under a creative commons license, allowing readers to fork and contribute to the story as they saw fit. In reflecting after the fact, the Wired team said something that stood out to me:
At Wired offices, you hear the question over and over again as we work on stories like the one you’re reading now: “Are you out of the story? I want to go in.” We have a version control problem. We publish Wired.com on WordPress. It’s a decent publishing tool, but when two people change a story at the same time, one of them doesn’t get her changes onto the final story.
We published our GitHub story on GitHub because it was meta-cool. But we also did it to see if GitHub might actually help us solve our problem.
Spoiler alert: it didn’t. GitHub’s great for a lot of things, source code chief among them, but it’s not for the faint of heart. There’s a great deal of command line, and general geekery involved that raise the barriers to entry just high enough to keep it out of everyday newsrooms and editorial workflows. 1
The Pitch: What if we could re-imagine WordPress’s ease-of-use and intuitively dumb-simple workflow to introduce a layer of GitHub’s collaborative fork-and-merge horsepower under the hood?
Users would have the ability to “clone” an existing post, make any changes they want, and then merge those change back into the original before publishing.There are four distinct use cases where this feature may come into play:
- Collaborative editing (by resolving two users’ conflicted saves – Wired’s example)
- Saving draft changes of already-published content
- Scheduling pending changes to already-published content
- Allowing users without edit or publish capabilities to edit and submit changes to content (similar to GitHub’s pull request system)
I’d imagine the workflow would go something like this:
- User without the ability to edit an existing post has changes to make
- User “forks” the post, making any change they deem necessary
- When done, user attempts to merge changes back into the original
- Post goes into standard WordPress “pending review” workflow
- Editor is presented with diff (using the built-in diff engine), and can automatically accept changes (if there are no conflicts), or manually merge the two if necessary
- Post is re-published with updated content, revision logs merged to reflect history
In a nutshell:
- Extends WordPress’s existing revision system
- Clone existing posts, edit, and “republish”
- Schedule changes to posts, including taxonomies and metadata
- Pending changes diff view, frontend preview of changes
- Using WordPress’s pending-review system, integrates with existing plugins for notifications, management, etc.
- Ability to store “commit messages” with each post revision to explain to others what changes were made and why
Automatically merges (non-conflicted) changes (based on existing diff engine)
- One sided changes – one overwrites the other
- Two sided non-conflict changes – automatically merge
- Conflicted changes – note conflicts in fork and prepare for re-merge
Post forking may make for a killer plugin 2 or piece of core functionality… and imagine if it could integrate with other collaboration tools like Edit Flow, or WP Document Revisions? As in Wired’s example, it has the potential to fundamentally change newsrooms and other editorial workflows. All of a sudden, any content becomes either publicly or privately collaborative. Pretty cool, huh? While it may be a bit ahead of it’s time from a human standpoint, from a technical standpoint, the technology’s there — it’s nothing new — just a matter of building it, and hopefully solving the dreaded “are you out yet?” problem.
Thoughts? Would you use this? What else would you like to see it do? Drop me a line, or let me know in the comments below?
Update (3/5): The plan right now is to submit this as a Google Summer of Code project, so if all goes well, look for the above-outlined functionality in a WordPress install near you towards the end of the summer. In the mean time, the continued thoughts/feedback is very greatly appreciated.
Update (3/27): It looks like WordPress isn’t participating in GSoC this year. Filing this idea under “someday”.
Update (6/13): Stay tuned. This may yet become a reality after all. ETA end of summer-ish.
Update (10/1): Introducing Post Forking for WordPress — a more collaborative approach to content curation:
Having recently given this a try — using GitHub to curate a collaboratively edited list of open-source alternatives to proprietary software — I know first-hand how off-putting GitHub can be to non-technical users. ↩
Full disclosure: two plugins, Revisionary and Duplicate Post exist, but they don’t take the idea nearly as far as the above proposes, nor do they do it in “the WordPress way”. I’d hope that even if the idea started as a plugin, it would eventually be incorporated as core functionality. ↩
If you enjoyed this post, you might also enjoy:
- Towards a More Agile Government
- Securing the Status Quo
- Twelve tips for growing communities around your open source project
- 15 rules for communicating at GitHub
- Why open source
- Five best practices in open source: external engagement
- Four characteristics of modern collaboration tools
- 19 reasons why technologists don't want to work at your government agency
- Ten ways to make a product great
- Everything an open source maintainer might need to know about open source licensing
- Why everything should have a URL
Ben Balter is a Staff Technical Program Manager at GitHub, the world’s largest software development network. Previously, as the Senior Product Manager overseeing the platform’s Trust and Safety efforts, Ben shipped more than 500 features in support of community management, privacy, compliance, content moderation, product security, platform health, and open source workflows to ensure the GitHub community and platform remained safe, secure, and welcoming for all software developers. Before joining GitHub’s Product team, Ben served as GitHub’s Government Evangelist, leading the efforts to encourage more than 2,000 government organizations across 75 countries to adopt open source philosophies for code, data, and policy development. More about the author →