I’m working on a new logo for post forking to use on the stickers and t-shirts that supports will be receiving. I’ve got three concepts so far. What do you think?

I’ve identified ten tickets for 0.3. https://github.com/post-forking/post-forking/issues?milestone=6&page=1&state=open

One of them, #84 is a large ticket will be accomplished over multiple releases. The biggest piece of it will be accomplished in #38, #37, and #97

If you want to help, jump on those tickets with comments. I’m also hanging out in the #wp-postforking room on irc.freenode.com if you want to chat.

v0.3 development is going to be starting soon. Let’s kick things off with an old fashion open thread here to suggest features.

I want 0.3 to be focused on the experience of post forking. This means https://github.com/post-forking/post-forking/issues/84 https://github.com/post-forking/post-forking/issues/38 and https://github.com/post-forking/post-forking/issues/37 will be my biggest priorities, but I’d like to here what everyone thinks. We will also continue to improve the unit tests and fixing outstanding issues.

Post below with your thoughts on what you want to see in 0.3. We will do an IRC soon as well to finalize the goals for 0.3

v0.2 was released last week. A fundraising campaign is also underway for the continued development.

I’ve created a v0.2 milestone, as I’ll be doing some work on this in order to add it to our VIP shared plugins repo. Austin Smith (@netaustin) may also be using it for a project and incorporating some post meta forking functionality.

I’ve created an IRC channel on freenode( #wp-postforking ). I’ll idle in it to keep it alive.

@benbalter / @danielbachhuber Would you be interested in having an IRC chat to go over the roadmap for what is needed for 0.2 ?

@benbalter should we use the Google Group you created as a public email list for the commit log? Github doesn’t yet support this natively, so we need to set up a mailing list somewhere.

Any thoughts on branches in terms of development? All for proper feature branching/merging. In the past, I’ve kept master in sync with .org’s SVN to avoid confusion for folks that stumble across the project for google, etc., and did most of the work in a `develop` branch, but up for others’ expertise. Thoughts?

Introducing Post Forking for WordPress

WordPress sets out to democratize publishing, and today the CMS gains an important new feature to that end: Post Forking.

WordPress Post Forking allows users to “fork” or create an alternate version of content and in doing so, sets out to foster a more collaborative approach to WordPress content curation. This can be used, for example, to allow external users (such as visitors to your site) or internal users (such as other authors) with the ability to submit proposed revisions. It can even be used on smaller or single-author sites to enable post authors to edit published posts without their changes appearing immediately. If you’re familiar with Git, or other decentralized version control systems, you’re already familiar with WordPress post forking.

How might you use it?

• Allowing users without edit or publish post capabilities to edit and submit changes to content (similar to GitHub’s pull request system)
• 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

Why this plugin?

• GitHub for Journalism — What WordPress Post Forking could do to Editorial Workflows

How does it work?

When a user without the edit_post capability attempts to edit a given post, WordPress will automatically create a “fork” or alternate version of the post which they can freely edit. The edit screen will look just like the standard post editing interface that they are used to. When they’re done, they simply click “submit for review.” At this point, the fork goes into the standard WordPress moderation queue (just like any time an author without the publish_post capability submits a post), where an editor can review, and potentially approve the changes for publishing. If the changes can be automatically merged, the original post will be updated, otherwise, the editor will be presented with the ability to resolve the conflicting changes. All this is done using WordPress’s built-in custom post type, revision, and diff functionality, so it should look familiar to most WordPress users.

Interested?

Download the plugin from the WordPress plugin repository, or fork the project on GitHub, or for more information, visit the Post Forking project wiki.

This version constitutes an initial release designed to showcase the plugin’s core functionality and is intended to be improved upon with additional features and refinements as the project evolves. Please consider contributing your time to help improve the project.

We’re all set with .org (get it? It’s a fork?), and both the GitHub repo and this P2 are now public. I’ve got a short post queued up for first thing tomorrow morning, and tagged v0.1 in both GIt and SVN.