 | newtonsongbird on Suggestions |
 | Kim Parsell on Core Contributor Handbook |
 | Lance Willett on We’re getting very close… |
 | Muhammad Abdi on Core Contributor Handbook |
 | Maor Chasen on We’re getting very close… |
During the latest dev chat we’ve decided to schedule a weekly bug scrub in IRC for the next few weeks each Friday at 11AM Eastern/16:00 UTC, for two hours. Please join us if you’d like to participate in reviewing the patches currently slated for 3.6.
Will need two volunteers to be the admins for GSoC, overseeing our application, mentor wrangling, and if we get selected, student wrangling. Good project management skills required, familiarity with core contributors a plus. Note: though most mentors will likely come from this group, it’s not my intent to pull devs away from development to be admins. Just posting here bc I know a number of project managers follow this blog. The admin volunteers would be coordinated via the community group and would work with devs across core, themes, and plugins as needed. If interested in volunteering as an admin, ping me. Thanks.
This is a rather late update, and will serve for the last two; apologies!
Last week, we talked about the locks that went in, and @markjaquith suggested that we replace the “lock” with a Gravatar, which I like quite a bit. Will experiment with that to see if it can work.
Today we chatted about the most recent update to #23220 posted by @azaozz, which integrates the work done by @asannad (AmitSannad on IRC), and adds a UI for selecting which you’d like to restore: 
In addition, if it’s found that you have an autosave that has failed, and have a newer version locally, you’re warned (either on the Posts list or Post itself), and linked to the UI that allows you to restore the content (post content and title only) and save at will:
It was brought up during the chat by @nacin that the UI included in the patch might be more than we need, and that we should decide what is best for the user regarding restores, and perform it for them. We continue to chat about this, and opinions are welcome!
Lastly, there is a patch from @mintindeed on #23295 currently waiting for integration! That patch, and the one on #23220 could use some testing — let us know if you run into problems on trac.
We’ll be meeting again this Friday at 2100 UTC (1pm PST).
As has been the case for many sessions now, Monday’s revisions office hours focused on changes to the UI. @karmatosed provided new mockups, influenced by a thread on the Accessibility blog. @adamsilverstein also posted a series of patches on #23396 that begin to implement the general direction we’ve chosen for UI updates (aside: we’ll do our best to keep future mockups on this ticket, for easier discovery; until now, most have been posted in the comments on these update threads). We are certainly approaching a consensus on the new design, but have held off on any significant UI-specific coding until we’re confident that our efforts won’t be wasted.
Beyond UI, there are patches on three tickets that could use testing: #16215, #22289, and #19932. @adamsilverstein and @westi are working on unit tests, which should help move the patch review along.
We should have new mockups to review during tomorrow’s office hours at 1500 UTC in #wordpress-dev.
[IRC log]
Here’s a recap of yesterdays office hours.
Work accomplished since last office hours
Major items discussed
1) Theme locations continues to be our biggest design challenge. We discussed a bunch of options and decided to go with checkboxes for theme locations for now – while we continue to stew on alternative approaches.
2) We discussed having settings at the top or the bottom, and settled on them being on the bottom.
On the docket
After that
p.s. @DrewAPicture, I added a title this time just for you. 
RE: title, “He can be taught!”
We also need to do an extensive round of RTL testing as well as completing docblocks for any new functions we’re introducing, @access private or not.
I can start on no-js testing this weekend.
I did a round of RTl testing/fixing (I’m not sure I would call it extensive, but I think I caught most everything).
I can start on no-js testing this weekend.
Awesome! Thanks for that.
I also added more complete docblocks to new functions in 23119.28.2.diff
I can help with browser testing. Are we covering ie7? Or just 8+?
Hi, very nice 
When you use Mega drop down menu, you can’t delete all children from main menu. It would be great if we can Expand/Collaspe main menu and delete all children sub menu from main menu
I asked @jkudish to gather some data around avg number of menu items per menu for sites on WP.com. Out of 1000 random sites (with at least one menu added), here’s what the distribution looked like:
Excluding the menus with zero items added, the average comes out to 5.
So, based on this data, should we make some sort of expand/collaspe menu item functionality a part of core, or keep it in plugin territory?
I think my preference would be to keep it as a plugin, but I’d love to hear everyones thoughts.
Just a small correction to the description above, it was 3000 sites, not 1000. A lot of them didn’t have any menus at all, which is why if you add up the above numbers you don’t get 3000
Also, I agree with @lessbloat, I think this is plugin territory.
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 patch commit-ready.
For the second, the biggest question was how we should handle revisions for post meta and taxonomy 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 core 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.
Initially I was disheartened that you guys were dropping metadata support, but read the irclogs and it makes sense and I’m glad their are still advocates for adding it back in later.
All of which I share only to say, THANK YOU, for such an open and transparent process. Really all the teams are doing a fabulous job and all the communication is hugely appreciated, so thank you for that and all the great work.
Tuesday office hours conflict (for me) with the WordCamp Base Theme chat, so I’ll note here that meta revisions are not in scope for 3.6.
While the relevant tickets (#20564 and #20299) marked as 3.6, we’ve spent a good deal of time on UI/UX, and that will likely continue to be the bulk of our focus for this iteration. @nacin marked both as 3.6 because they block #23314, but we (@westi, @adamsilverstein, @karmatosed, and I) don’t have the availability to address them at this time.
Hi Daniel — you previously requested for some workflow examples. Here’s an example workflow from a WordPress.com VIP publisher:
1) Writer puts text in WordPress and saves as “pending review” so the editor knows its ready.
2) An editor goes in and edits the text in WordPress and schedules the post to publish, or publishes immediately if breaking news.
3) The post goes live.
4) A producer goes in and updates the appropriate fields, if they are not already filled out (category, social text, SEO headline etc). Also could fix any typos found post-launch. Probably wouldn’t need approval before going live.
5) A photo editor goes in and adds a featured image (these changes could go live without approval) and updates the post.
Revisions:
Suggestions:
We started today’s office hours by reviewing @karmatosed’s latest mockups for the revisions screen. We’re in agreement that these reflect the direction we’ll take, so @adamsilverstein will begin coding the changes in preparation for Monday’s meeting. As some concerns have been raised about the use of red and green, @karmatosed will post to the Accessibility group’s P2 asking for feedback on the current mockups. She will also explore the use of patterns to differentiate additions and deletions, as suggested by @helen.
@westi made a few suggestions, based on his recent experiences with Revisions, which we’ve agreed to incorporate. For clarity, the current version will be included in the revisions list to provide a stronger connection with the overall revisions workflow. Second, we decided that when first landing on the revision screen for a given post, we should show the diff of the current version and its immediate predecessor revision; since most users are probably looking for this anyway, why not save them a step?
Lastly, we chatted about the status of code-oriented tickets scoped for 3.6. A few (#16215, #22289, and #19932) have patches, which we’ll be reviewing and providing feedback on before Monday’s meeting. With any luck, we can land at least one in Core before the next dev chat. Beyond that, development on the remaining tickets should progress over the weekend, with the aim of having more patches to review for our next office hours.
For reference, the tickets that are in scope for 3.6 (at least at this point), can be found here.
[IRC Log]
@esmi from the Accessibility team has posted up a thread we can keep an eye on and I’ll use to feed back into mockups.
We had some good points raised in the discussion over on make.accessibility and I’ve done 2 mockups from this. One is a combined view, another is a merged to just show.
Here for reference is the thread which talks about the tags we should use for this.
http://make.wordpress.org/accessibility/2013/02/08/post-revisions-in-3-6/
i posted code diffs for discussion at our next meeting, see #23396.
We’ll have a patch clearing session in IRC on Friday, February 8 at 11AM Eastern/16:00 UTC, for two hours. Let’s aim to go through the commit candidates and resolve some of the other tickets currently slated for 3.6.
Yesterday’s meeting focused on revisions to the revisions interface . @lessbloat joined us to ask some great questions, and helped refocus the UI changes that have been proposed and mocked up so far. We started off by trying to identify the major uses of revisions, and settled on two primary cases: undoing mistakes by finding the last correct revisions, and reviewing changes as part of an editorial workflow.
In light of those focuses, we’ve decided to revisit the UI mockups we’ve (namely, @karmatosed and @adamsilverstein) worked on so far. The general consensus is that they’ve become overly complicated, and led to feature creep (looking at you, line-by-line accept/reject capabilities). @karmatosed is working on some new mockups for Thursday’s office hours. One possible source of inspiration may be @benbalter’s post forking plugin.
On the code side, @mdawaffe worked out a pretty comprehensive patch for the display of incorrect authors on revisions (#16215). We’ll be reviewing that, along with the patches added to the other tickets we’ve scoped for 3.6. As was the case when I last posted, progress is slow at this point due to travel and the ongoing UI discussions.
[IRC log]
i posted patches for testing that implement some of the mockup concepts we talked about during our meeting here – #23396
I’ve got some more mockups for discussion in the meeting today here:
I spent some time with @benbalter’s plugin and merged that with some of the ideas that seemed ‘easy wins’ from a UI view. It’s mainly a tidy up in a lot of respects. I did one with notes but understand this feature probably will not be included – I just wanted to see what it looked like.
I felt the picking in the post forking plugin worked well for that instance but may be overly complicating for us as the ‘new’ would always be the newer version so that’s what I was keeping to by you just picking 2. I didn’t add a submit or confirm as figured if you picked 2 it could reload – we may want to reconsider this as perhaps a pause through clicking something could be useful.
Not a whole lot to discuss today – working away at patches on #19570 (edit form UI) and #23347 (theme compat). Could use a patch on #15490 (retrieval of oEmbed data and previewing, which I suspect will become relevant to the edit form UI) and testing of #23282 (audio/video shortcode and player) and #16047 (list table column).
Oops, also meant to mention round 3 of user testing: http://make.wordpress.org/ui/2013/02/04/round-3-of-post-format-ui-user-testing/
lessbloat, and 2 others are discussing. 
Oops I missed today’s meeting.
I am working on some revisions to my patch based on feedback from last week’s meeting, unfortunately work is killing me this week so it will probably be the coming weekend (Feb 16–17) before I get a revised patch up there.