The Road to 3.6 Beta 1

#3-6

Dropping Editorial Flow

I’ve decided to drop the Editorial Flow feature from the 3.6 roster. A few things happened. We looked into what the main feature (“forking” a published post and allowing it to be edited then reintegrated) would involve, and found that there were some really fundamental hurdles that were unlikely to be resolved in the time given. A lot of time was spent on the planning stage, and we just kept surfacing more questions. Moreover, because the hurdles were so low-level, they would have required a significant amount of time from a core lead like me, @nacin, or @ryan — time that we just didn’t have to give this cycle due to other responsibilities. What that left was #12706 — a somewhat related ticket with a long-running monster patch. This similarly needed (and still needs) a core lead to dedicate a lot of time to planning, reviewing, and committing it. That might happen, or might not. It didn’t seem fair to keep @danielbachhuber and @kovshenin responsible for something that might or might not make it, subject to other people’s availability.

Though disappointing, this effort wasn’t wasted. We learned a lot about the challenges involved, and we’re better positioned to tackle it in the future with more advance planning and a better understanding of the core team resources that need time dedicated to it.

#3-6

A first draft of the Twenty Thirteen theme…

#3-6, #bundled-theme, #theme, #twentythirteen

Feature Team Updates and Office Hours

The WordPress 3.6 feature teams should be updating here on make/core twice a week, on the following schedule. List any major developments, summarize any notable IRC conversations that happened, call for help where coding, testing, discussion is needed, etc. They don’t need to be long, unless a lot of stuff happened. The idea is that people who aren’t in IRC and Trac every day can still stay up to date on features and jump in when they can. And it will keep the teams aware of their progress (or lack thereof) on a more regular basis.

Monday and Thursday

  • Autosave/Post Locking
  • Nav Menus
  • Post Format UI

Tuesday and Friday

  • Editorial Flow
  • Core Maintenance and Architecture
  • Revisions

Next, while many features are still being actively planned, the feature teams should hold IRC office hours where more realtime discussion can take place to get the features scoped and planned a little better. Feature teams should announce these hours here on make/core (can be part of their twice-weekly updates).

#3-6

Agenda for the weekly dev chat 1 Feature…

Agenda for the weekly dev chat:

1. Feature team updates
2. Set up schedule for more frequent feature team updates
3. Unstick anyone who is stuck
4. Rallying call for Ryan’s code maint ticket list

#dev-chat

WordPress 3.6: Code Maintenance and Architecture

#3-6, #maintenance

Git Mirror History Breakage

A few years ago, I started publishing a mirror of WordPress on GitHub. It was subsequently promoted to WordPress/WordPress. What I neglected to do, however, was provide an appropriate authors.txt file, until recently. That means that earlier commits are attributed to dummy e-mail addresses and as such cannot be associated with user accounts on GitHub. Considering the recent introduction of contributions on GitHub, this seems a shame. Also, if we were to move to Git in the future, we would probably want our official mirror to have the best possible data.

Proposed

That we re-run the git-svn import with a proper authors.txt file.

Upsides

We’ll have a proper Git mirror with good and consistent author data, that we can, if desired, use for a future migration to Git. Commits will be properly attributed in GitHub.

Downsides

This will break Git history. If you have a Git checkout of WordPress, either standalone or in a submodule, that’ll mean that you’ll have to rebase your master branch off of origin (or even better, blow the whole thing away and re-clone).

So: thoughts? Would this ruin your day?

#git, #github

WordPress 3.6: Distraction-Free Writing improvements

Distraction-Free Writing (DFW) made its debut in WordPress 3.2. It’s good, but it has some problems:

  • It’s hard to discover. A tiny button that doesn’t stand out from other buttons.
  • The transition is a bit jarring. Your content goes away, you land on another screen, and your content reappears. It feels like there is a cost to switching.
  • It isn’t as fully-featured as it should be. If it isn’t capable of easily (and by that I, I mean without keyboard shortcuts) doing the majority of the formatting people need to do while writing, people are going to be disinclined to use it.
  • It could use some polish. Some of the interactions are janky, and it’s not very responsive to large screens. There are strange issues that happen when you get to the end of a line or do a line break near the bottom of the editor. The Esc key doesn’t work when in TinyMCE. Lots of little stuff like that.

What I need is someone with CSS skills and JS competency to take on a bunch of little improvement projects for DFW. If you have those skills and care about making a beautiful and functional distraction-free writing experience for WordPress, speak up!

#3-6

WordPress 3.6: Autosave and Post Locking

I want, as a major 3.6 bullet point, that we should never lose posts due to expired cookies, loss of connection, inadvertent navigation (even if AYS’d), plugin or core errors on save, browser crashes, OS crashes, cats walking on keyboards, children drooling in keyboards, etc. I want people to trust WordPress with their posts. They should never fear that something they’ve spent time creating or editing should go away due to their mistake or ours or that of a third party. Mistakes and errors should be recoverable. I can’t stress enough how important it is that people believe this and have good reason to believe it. If a post gets lost, there is a catastrophic loss of trust, that could take years to be regained (if indeed it ever is). This is people’s time and their creative output we’re talking about. If we’re not valuing those things above all else, then our priorities are seriously out of order. This is an all-hands-on-deck item for 3.6. Even if you’re not actively working on the code or the copy or the UI or the UX I want you to be thinking about ways in which WordPress could better treat your creative output as the valuable artifact it is.

Things this will likely involve:

  • Local storage of post data while editing, in-between autosaves and manual saves.
  • More frequent “heartbeat” pings to the server (allowing data to hitch a ride at certain intervals, and also allowing us to quickly deliver messages back from the server about events).
  • Real and more granular post locking. Right now we just have a wimpy notice that isn’t a good deterrent against people simultaneously editing a post and overwriting each other’s changes.
  • Probably some interaction with the team working on improving Post Revisions.
  • UX work for making recovery from failure scenarios smooth, clear, and worry-free.

@aaroncampbell and I have chosen @azaozz to lead this, as it will probably be very JavaScript-heavy. There are a lot of moving parts here, so please leave a comment if you’re interested in this important, heroic, virtuous endeavor. 🙂

#3-6, #autosave-and-post-locking

WordPress 3.6 Planning Session

I hope everyone enjoyed the holidays! We’re back to our regularly scheduled IRC meetings tomorrow, and are going to start by scoping and planning out the 3.6 cycle. Wednesday, Jan 2, 21:00 UTC. Please make every effort to attend! The theme I’m proposing for 3.6 is “Content Editing”, so especially start thinking about editing, editorial workflows, revisions, autosave, DFW, etc. Also be thinking about what you’d like to work on and how much time you can commit this cycle.

#3-6, #irc, #planning