Updates from Daniel Bachhuber Toggle Comment Threads | Keyboard Shortcuts

  • Daniel Bachhuber 2:27 pm on March 7, 2013 Permalink | Reply
    Tags: v0.2   

    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.

     
    • Getting off methadone 9:49 am on June 4, 2013 Permalink | Reply

      Woah! I’m really enjoying the template/theme of this blog. It’s simple,
      yet effective. A lot of times it’s challenging to get that “perfect balance” between superb usability and appearance. I must say that you’ve done
      a fantastic job with this. In addition, the blog loads super
      quick for me on Safari. Excellent Blog!

  • Daniel Bachhuber 12:55 pm on October 1, 2012 Permalink | Reply
    Tags: commit notifications,   

    @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.

     
  • Daniel Bachhuber 12:22 pm on September 21, 2012 Permalink | Reply  

    @benbalter can you add @mjangda to the Github repo so he can check out the code?

     
  • Daniel Bachhuber 1:44 pm on September 7, 2012 Permalink | Reply
    Tags:   

    After temporarily disabling custom capabilities, I’ve created my first fork! Doing so raises a few questions though:

    • What is the plugin supposed to be doing? What problem does it solve?
    • Do I publish a fork? If not, how do I merge it back into the original?
    • Should forks be a public post type if they aren’t intended to be published?

    Based on my prior opinions, forks shouldn’t be a public post type by default. The point of “creating” a fork is to be able to make edits to another post type, and then be able to “submit a pull request” to have your changes merged back into the original. This is what v0.1 should be.

    Thoughts?

     
    • Benjamin J. Balter 2:53 pm on September 7, 2012 Permalink | Reply

      I had two potentially conflicting design philosophies when I was sketching things out.

      1. Mirror GitHub as much as possible — it’s a well thought out workflow that most folks understand
      2. Use native WordPress functionality as much as possible — it’s a well thought out workflow that most folks understand

      Publicness: I remember going back and forth on whether forks should be public, and the only reason I fell on the public side was because if I fork a GH repo, my work on it, is by default, public. I don’t know how that would play out on the front end in a WordPress context, but that was the logic. Could go either way though. There’s something to be said for the possibility of a public revision history down the line, or ability to see pending “pull requests”, etc.

      Publishing: Theoretically, if I don’t have the `publish_post` cap, the publish button should be the standard submit for moderation. If I do have the `publish_post` cap, or am reviewing something from the moderation queue, I should have the normal publish button. The plugin should be intercepting the publish action and merging the fork into the parent post or presenting the conflict for resolution. I think this makes sense from a UX standpoint as you’re “publishing” the changes. Think of this less of a standalone CPT and more of fork of the parent post. Once published, nobody should have `edit_published_fork` caps, as they serve simply as a history, e.g., see this users forks (unless it makes sense to use the parent’s revision (the merge) and use metadata or some magic to query). The use case here was more for news-ish sites to allow readers to submit corrections, and have a running log of their contributions. If the forks are public, we just use author pages and don’t have to code anything. May make sense to back-burner this, or make it a filter for users that want the feature. Was in the original spec.

      Purpose: Originally, http://ben.balter.com/2012/02/28/github-for-journalism-what-wordpress-post-forking-could-do-to-editorial-workflows/

      • 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’m not strongly opinionated on the public/private thing. If you think the contribution archive makes sense as a feature and that’s the way to do it (thinking author archive for a CPT), great, if not (or if there’s a better way to do it), let’s flip it.

    • Daniel Bachhuber 4:32 pm on September 7, 2012 Permalink | Reply

      I remember going back and forth on whether forks should be public, and the only reason I fell on the public side was because if I fork a GH repo, my work on it, is by default, public.

      If it’s a private repo though, the fork remains private. In the publishing world, most work remains private until it goes public. I think that should be the default option with the ability to enable public forks if you need.

      If I do have the `publish_post` cap, or am reviewing something from the moderation queue, I should have the normal publish button. The plugin should be intercepting the publish action and merging the fork into the parent post or presenting the conflict for resolution. I think this makes sense from a UX standpoint as you’re “publishing” the changes.

      This is not intuitive in my opinion. Instead, something like “Merge” would be more descriptive. Similarly, most of the other options in the post submit box could be removed.

      If you think the contribution archive makes sense as a feature and that’s the way to do it (thinking author archive for a CPT), great, if not (or if there’s a better way to do it), let’s flip it.

      Maybe this should be v0.2. It’s not terribly obvious as it is, but there certainly is great potential in allowing for public forks, showing version history and forking contributions, etc.

      • Benjamin J. Balter 4:38 pm on September 7, 2012 Permalink | Reply

        In the publishing world, most work remains private until it goes public.

        Totally agree. Just trying to think through the flow. That should be the case with public forks, no? If it’s not published (draft, private), it’s not public. If it’s published (meaning it’s already merged into live post), it’s public, no?

        Similarly, most of the other options in the post submit box could be removed.

        May make sense to (either now or down the line) remove the standard publish metabox and add our own simpler one? Was just trying to keep the UX as fluid as possible between forks and posts.

        Maybe this should be v0.2…. there certainly is great potential in allowing for public forks, showing version history and forking contributions, etc.

        #worksforme

        • Greg Linch 12:59 am on October 14, 2012 Permalink

          A potential bug with merging a forked draft back into a draft:

          I did: I forked a draft post and merged it back
          I saw: It published
          I expected: It to only merge — not publish

          Sorry if I missed this elsewhere (I’ve been following all the GitHub threads!), but will this be fixed going forward?

          I can imagine many use cases where this would be very problematic if not. If it stays as is, the admin language should be changed to “merge and publish” for drafts and “merge and republish” for previously published posts.

        • Daniel Bachhuber 1:07 am on October 14, 2012 Permalink

          That’s a bug. Merging into a draft shouldn’t cause it to publish. File a Github issue and I’ll take a look?

        • Greg Linch 10:27 am on October 14, 2012 Permalink

c
Compose new post
j
Next post/Next comment
k
Previous post/Previous comment
r
Reply
e
Edit
o
Show/Hide comments
t
Go to top
l
Go to login
h
Show/Hide help
shift + esc
Cancel