Tag Archives: editorial flow

Daniel Bachhuber 1:52 am on February 8, 2013
Tags: , editorial flow   

Editorial Flow Update, 2/7

Editorial flow is making progress and hitting interesting questions to answer. Our two primary tickets right now are #12706 and #23314.

For the first, we’re waiting on feedback on the approach from @nacin. Once we’ve gotten confirmation it’s the right direction, I’ll continue working to make the patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. commit-ready.

For the second, the biggest question was how we should handle revisionsRevisions The WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next/Previous buttons). The display indicates what has changed in each revision. for post metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. and taxonomyTaxonomy A taxonomy is a way to group things together. In WordPress, some common taxonomies are category, link, tag, or post format. https://codex.wordpress.org/Taxonomies#Default_Taxonomies. terms. In the interest of getting to a committable patch, we’ll be dropping post meta / custom taxonomy support in favor of just being able to stage edits for the title and body content. Furthermore we’ve decided it would be worthwhile to add a new post type property so this functionality is opt-in. Posts and Pages in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. will receive this by default.

Our primary goals are to have commit-ready patches for both tickets by the beginning of next week. Konstantin’s secondary goal is to chat with @westi and @ethitter and see whether revisions for post meta is within scope for 3.6. My secondary goal is to go through other editorial flow tickets and touch base with where each is at.

Next office hours are Tuesday, February 12th at 10 am PT / 1 pm ET / 1800 UTC.

Office hour log

#3-6, #editorial-flow

Daniel Bachhuber 5:01 am on February 1, 2013
Tags: , editorial flow   

Editorial Flow Update, 1/31

Kovshenin and I held office hours today but we didn’t discuss too much. Both of us have a pretty good understanding of what work needs to be done — we just need to do it.

One thing that’s come up is that #20299 (Preview changes on a published post makes all post metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. “live”) is a blockerblocker A bug which is so severe that it blocks a release. for editing already published posts. So we’ll have to figure out what we’re going to do for that.

I’d like for us to have demoable code by the next office hours: Tuesday, February 5th at 10 am PT / 1 pm ET / 1800 UTC.

Office hour log

#3-6, #editorial-flow

Konstantin Kovshenin 11:45 am on January 29, 2013
Tags: , editorial flow   

Editorial Flow office hours today Tuesday at 1800…

Editorial Flow office hours, today (Tuesday) at 1800 UTC.

I’ve been working on some mockups over the weekend of possible UIUI User interface implementations for revising published content. Still very draft and a bunch of unanswered questions, nonetheless here are some pictures:

  • The “Save as Draft” and “Publish Changes” flow: http://cl.ly/image/1b401P3B0d3U
  • “Update” vs “Save as Draft” with a drop-down button: http://cl.ly/image/2o0C3b3r252d
  • “Save Changes for Later” vs “Discard” in a drop-down button: http://cl.ly/image/0y0T0Y0H0M1X
  • Everything hidden in a misc-publishing-action: http://cl.ly/image/2J0e0A3N0F2b
  • What a contributor would see: http://cl.ly/image/1Q2V1Q3L3L46

So the agenda for today’s office hours is to discuss these, and maybe pick a direction (even if it’s totally different from the list above). Since there’s an overlap with the RevisionsRevisions The WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next/Previous buttons). The display indicates what has changed in each revision. team, would appreciate if @westi and/or @ethitter popped in.

#3-6, #editorial-flow

Daniel Bachhuber 7:34 pm on January 24, 2013
Tags: , editorial flow   

Editorial Flow Update, 1/24

Kovshenin, Nacin and I chatted today in IRCIRC Internet Relay Chat, a network where users can have conversations online. IRC channels are used widely by open source projects, and by WordPress. The primary WordPress channels are #wordpress and #wordpress-dev, on irc.freenode.net. about scope for editorial flow in 3.6. To help narrow things down, we’re now focusing on two things:

1) “Finishing” the existing APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. such that you can register new post statuses with expected results (no bugs, etc.).

Last week, Nacin and I had a long conversation about how enhancing the post status API in various ways could lead to complex, fully-featured workflows. We discussed again yesterday after the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. IRC chat, and decided these enhancements still need more conceptual development. Instead, we’ll be focusing on the extent of #12706‘s description:

A developer should be able to register a custom post status using register_post_status(). The adminadmin (and super admin) UIUI User interface (including post submit box and quick edit) should reflect this new custom post status. Furthermore, there are many hard-coded references to ‘draft’ and ‘pending’ statuses in core that should properly use the post status API.

All existing arguments to register_post_status() should be fully implemented, should also support per-post-type arguments. As things get implemented across core, there will likely be a need for supporting capabilities and bits of API.

I hope to have a working, testable implementation of this by next week, using existing patches and maybe some new code.

2) Allowing already published posts to be revised without being updated immediately.

We discussed a few possible implementations of this. Our conclusion is to go with the simplest possible implementation, as there are already a few plugins to handle more complex implementations.

Right now, it’s looking like this: a ‘draft revision’ can be created of an already published post. If a ‘draft revision’ of a post exists, it will appear in the post editor (instead of the published content). Anyone with appropriate permissions can make edits to the ‘draft revision’ without having those changes go live. Then, at some future point, the ‘draft revision’ can be pushed live to take the place of the original published post.

Kovshenin will be working on wireframes for this over the weekend.

We want your help!

  • What use cases do you have for the second, user-facing feature? The more details you can provide, the better.
  • Have you come across software which does the second piece well? Notably, it would let users easily choose between pushing their update live immediately, or continuing to work on and save their changes as draft.

The next office hours will be Tuesday, January 22nd at 10 am PT / 1 pm ET / 1800 UTC.

https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2013-01-24&sort=asc#m539794

#3-6, #editorial-flow

Daniel Bachhuber 11:30 pm on January 18, 2013
Tags: , editorial flow   

Editorial Flow Update, 1/18

Nacin and I chatted today about what we want to do about editorial flow in 3.6. At the crux of building any new features is completing the APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. for registering new post statuses.

There’s an existing patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. in #12706 which solves some, but not all of the problems, which is probably why it’s been punted release after release. The problems can be understood as the following questions:

  • How are custom statuses related to post types? Are they global? Can they be assigned to only some types? Can they have different properties for different types?
  • How can we describe transitions from one status to another? How does the current status (and the state of the post in general) inform which statuses are available? How are capabilities used to affect which statuses are available? How do we describe the ability to access or affect a post based on its current status?
  • How do custom statuses factor into coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. UIUI User interface?
  • How do we define and/or extract the special features of existing core statuses?

The most substantial question is the last one. It’s worth reading through the chatlog in understanding how we got there as there’s a fair amount of exploratory thinking:

https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2013-01-18&sort=asc#m535910

The primary project right now is tracking down each of those special use cases. You can help out!

A “special use case” is a particular way the status (or statuses) manifests itself in core behavior. For instance, ‘draft’ and ‘pending’ appearing in a dropdown when editing an individual post is one manifestation of a special use case. When identifying these special use cases, please point to all relevant lines of codeLines of Code Lines of code. This is sometimes used as a poor metric for developer productivity, but can also have other uses. and indicate the core statuses affected.

Here’s the Google spreadsheet:

https://docs.google.com/spreadsheet/ccc?key=0An-ruHGRV0xZdG1SOWJZcW9ORjlrNFZYY0VkQTBmYUE

The secondary project right now is identifying use cases for custom post statuses. For example, as Nacin and I got to in the chat, Edit Flow’s custom status support is used for essentially creating new, labeled versions of the ‘draft’ status; essentially, establishing a workflow before publication:

pitch -> assigned -> in-progress -> ready-edit

If you were building a ticketing system on WordPress, however, you might have all public statuses like this:

new -> assigned -> resolved -> verified -> closed -> rejected

It would be tremendously valuable to have a variety of established use cases to play with once we start poking at the API. The more details for each use case the better.

The next office hours will be Tuesday, January 22nd at 11 am PT / 2 pm ET / 1900 GMT.

#3-6, #editorial-flow

Aaron D. Campbell 9:00 pm on January 7, 2013
Tags: , editorial flow   

WordPress 3.6: Editorial Flow

I’m really excited to see our editorial flow get some love in the 3.6 cycle! We always want to be as extensibleExtensible This is the ability to add additional functionality to the code. Plugins extend the WordPress core software. as possible and post statuses are one of those places where we’re not near as good as we should be. The plan goes something like this:

  1. Fully support the existing register_post_status() APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. in coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.
    • Make sure things don’t break when you add your own custom statuses
    • Update the metaboxMetabox A post metabox is a draggable box shown on the post editing screen. Its purpose is to allow the user to select or enter information in addition to the main post content. This information should be related to the post in some way. UIUI User interface to show any newly registered statuses in the drop down, etc.
    • Add a ‘moderation’ flag so that unpublished statuses can be explicitly identified
    • Support for non-standard public post statuses
  2. Enhance the existing API
    • Add support for registering post statuses to specific post types
    • Allow for caps checks on different post statuses
    • New remove_post_status() function for removing an already-registered post status
  3. Editing workflow for already published content

Additionally, we hope to address some issues around post metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. for revisionsRevisions The WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next/Previous buttons). The display indicates what has changed in each revision., which is tightly related to the workflow for already published content.

@markjaquith and I have chosen Daniel Bachhuber to lead this. If you’re not sure why, just Google WordPress Edit Flow and it’ll all make sense. There’s a lot of heavy-duty under the hood work here, so please leave a comment if you’re interested in lending a hand.

#3-6, #editorial-flow