This is the official blog for the core development team of the WordPress open source project. Follow our progress with weekly meeting agendas, project schedules, and the occasional code debate.
Current Dev Cycle
WordPress 3.3 has been released. We are currently recovering, reviewing trac tickets that didn't make it into 3.3, and getting ready to plan for 3.4. Primary development of 3.4 will likely begin around the 3rd week of January.
Blog post on: Friday (this counts for an update on Friday!)
Current cycle description: The Max Cutler Hunt
Max took the time to go through xml-rpc related tickets and post details about them. Eric and I will be going through his bugfix category of tickets this cycle.
Most of these tickets have already had some review and are likely ready to go. A few may need a bit more polish before they are commit ready.
Last week was more of an old school group status check and less of a new-process meeting (my bad, I had a time conflict). Let’s try to get back to the stuff we said we would start doing.
First we’ll review past meeting to-dos and make sure everything is done that is supposed to be (or see if there’s anything that is supposed to be done by now but isn’t).
Check in with each team to ID state (just finished scoping, already developing, or tested and commit-ready patch posted) and plug into schedule based on state + ux needs
Review each team’s planned scope/timing for 1st cycle
Assign days to each team for putting up weekly status posts on this blog (and add authors to site if needed)
Choose ‘office hours’ for each team to be in this channel and meet to chat re progress and/or chat with community members who are working on related tickets and have questions or need patch review
See if there are any new sub-teams we can form to get cracking on more feature dev
ID to-dos for each team member for next week
Ticket discussion: people not on an assigned team who have posted a patch on a ticket can ask for core team to check it and give feedback
The below notes are a discussion point of reference for today’s chat. This is NOT a feature list AT ALL. This means you, wpcandy and wptavern! Seriously, these are just notes so we talk about stuff, not features we are building.
::::::::::::::::::::::::::::
“The ‘Customize Your Site’ Release (a.k.a. the one that helps you make things look the way you want them to look)
Features: a ‘configure and activate’ wizard (Code Name: Gandalf), new default theme, individual improvements within Appearance and/or that show up on the front end
Core Team: Ryan Mark Westi Ozz Nacin Dion Koop Cave
54 possible volunteers”
========================================
Feature Possibilities:
Twenty Twelve theme – Matt, Lance
Framework for configure and activate (theme + associated custom header, background, menus, widgets) – Koop, Ocean
live preview of theme changes
activate without configure
drag and drop sidebars/widget areas from old theme to new theme
configure a new theme, with preview, and then push that theme live
easier static front page process
Better multisite support – Mark, Pete
improve UI
network enable v activate (parity with plugins)
subdirectory installs
get rid of ms-files.php (performance win)
autocomplete usernames or site names for network admin – Drew, japheth
Language Packs (can we find some language that makes this more understandable to the average user?) – Nacin, Dion, Sergey
Project: PinkPonyPress
MVC
Database abstraction
Smarty templating
Better theme finding – Helen, Mike S
infinite scroll on themes screen
multiple screenshots per theme
Better widgets – unassigned
widget area locations
widget preview, explicit save
clean up widgets screen, make it more streamlined
Better headers – Aaron and sabreuse
variable height
choose from media library
Better backgrounds
choose from media library
Settings
title tag as a setting instead of owned by theme – Cave, Boren
meta description tag in general settings – Cave, Boren
Media
links in captions azaozz
imgmagick color profiles?
gallery wysiwyg if someone works on it
Editor
TMCE improvements – azaozz, stas
Mobile
Work well in iPad/Fire (responsive CSS) Azaozz, georgestephanis
Looks like a good list to start from. Not that we’re voting but +1 to easier static front page process and widget UI.
I know the list isn’t inteded to be exhaustive, but hoping ticket 18179 (MetaBox Class) stays in and gets handled this round. Also wondering if anyone is interested in ticket 15971 (sorry but it’s well beyond my skills to offer a patch for this one).
Too bad I missed the chat today. What exactly is “Project: PinkPonyPress”? I’d be interested in participating in that set of features if it will in fact get worked on.
Also, what happened to a possible json API (to compliment XML-RPC)? Thought there were talks of that for 3.4…
Was there any talk about how the 54 volunteers (I included) would get their tasks assigned?
What about the WP Settings overhaul and the proposed Met Box class? I know that this is NOT feature list, but they sound cool.
Tom Lynch
10:09 pm on January 24, 2012 Permalink
| Reply
I would like to know about this as well as I have been waiting and waiting for nearly a year for this feature and it keeps being pushed back, 3.2, 3.3, 3.4, 4.0???
For settings overhaul, in addition to the UI work in the dashboard it will require new API stuff. We have limited core developers and need to prioritize based on the things that will improve WP for the greatest number of users. Settings just hasn’t trumped other stuff yet.
When we talked about process in today’s dev chat, one thing I forgot is that at core meetup we agreed that we should post the notes and action items from each dev chat, then review the action items at the beginning of the following week’s chat to keep track of things. So here goes!
Today’s meeting focused on the process to be used for the 3.4 dev cycle and the overarching concept of the release scope. To read through it line by line, see the IRC logs for the January 4, 2012 #wordpress-dev chat.
Core team presence: Jane, Ryan, Mark, Nacin, Koop, Dion. Late arrivals: azaozz, duck_. Absent: westi, matt.
Agenda: Review new process proposal that came out of Tybee core meetup, discuss; discuss potential focus for 3.4 release cycle; get statements of interest from people interested in taking more formal contributor role in this release.
Process
At Tybee meetup, I proposed we experiment with our process to try and overcome some of our historical downfalls (lack of good time estimation, resource bottlenecks, lack of accountability, unknown/variable time commitments/disappearing devs, overassignment of tasks to some people, reluctance to cut features to meet deadline), and the core team worked as a group to come to the following process proposal.
Pairs/Teams
We’ll divvy up feature development in pairs/small teams rather than assigning anything to one person. Will hopefully lead to better code, happier coders, and more accountability.
Each pair/team will ideally have a lead/committer teaming with up-and-coming contributors who want to commit to working on something specific. Leads, committers, and trusted core contribs will be assigned to a team. Newer contributors can volunteer to work with a specific team but probably won’t be part of the core pair if we’re not familiar with your work yet. This will hopefully make it easier for people to get involved and make connections with the core team instead of lingering unnoticed on a ticket for months at a time.
Each team is responsible for their feature being delivered on time and meeting interim deadlines (scoping, blog posts, posting patches, etc.).
Each team will only be allowed to claim one feature at a time, and may not claim another until the first is complete. No more claiming multiple features and working on them simultaneously.
If a partner/team member goes MIA, rest of team needs to find out what’s up, and if something is seriously wrong, escalate to my attention.
We’ll have a list of who’s working on what worked into the 3.4 schedule page.
Schedule
2-week cycles, no soft edges. Every two weeks there is a bit of discovery, a chunk of development, and a period of testing/fixing within the team.
Overlapping team cycles. The 2-week cycles will start on a rotating basis so that teams will be in different phases at all times, allowing for fewer bottlenecks and a greater ability to weigh in on assorted projects. In between each cycle will be several days dedicated to Trac maintenance/bug fixes and tickets related to that team’s project, so that casual contributions won’t pile up waiting for a committer to take a look.
Every week, the pair/team must post a progress report to wpdevel (once we have team assignments, we’ll make a schedule for this, like we did with gsoc student posts).
At the end of the two week cycle, team must deliver their scoped deliverable (generally a patch). If they are late, a warning will be issued. If they miss the deadline on 2 of the cycles, the feature will be reconsidered for inclusion in 3.4.
Time Commitments, Time Tracking
Each team will estimate how long each feature should take (# hours, # days – estimate both total time working on it, and how long that will be spread over based on team member schedules).
We’ll have some mechanism for reporting time spent on the feature so that we can see how our estimates compare. Not sure if this will be manual or if we’ll use a trac plugin. Investigating options now. Individual “it took this long” stats will be private, but the aggregate “this feature took this long” will be public. This will remove any reason to fudge the time reporting out of fear of looking too slow.
Like in any job or volunteer gig, we’ll ask people who are assigned to teams to make a specific time commitment per week to working on core in their team. We understand that circumstances change and the time commitments may need to be adjusted along the way, but this is also intended to help us do a better job of preparing scope and using stats to see how we did. If we’ve scoped features that look like they’ll require a total of x hours per week but we only have y in time commitments, we’ll know up front to start trimming scope. Note: making a formal time commitment will not be necessary for casual contributors, only those assigned as an accountable party in a pair/team.
Each two-week cycle will be another chance to get better at estimating how long things will take, and over time we will improve at this as a group.
Scope
3.3 was in some ways a multi-featured mess without a unifying theme. This meant lots of disparate stuff going on at once, and a number of features getting pulled due to timing. We want to get back to the idea put forth a year ago about having one overarching concept/goal/theme per release, that all new feature development fits into. We agreed that 3.4′s “theme” would be, “Making it easier to make your site look how you want it to look.” Shorthand: Appearance/switching themes. The idea is that a combination of front-end features, dashboard features, and under-the-hood improvements all tied to managing your site’s appearance will be the focus of 3.4. It will also include smaller things that don’t live in the appearance section but are related to the overarching goal, such as making it possible to have links in image captions. Make sense?
The individual features will be selected next week, and the proposed list of possibilities will be put up before then in a separate post. We’ll figure out teams, everyone will do their scoping exercises for the features they are interested in working on, and then next week we can hopefully start nailing down who’ll start with what and get the final project plan in place for a dev cycle start the following week.
High-level, the features would likely include: a theme-setup wizard that would incorporate an option for configuring all the appearance-related stuff before activating a new theme (speaking of, Twenty Twelve is targeted for 3.4), and then specific improvements around menus, widgets, backgrounds, headers, easier static front page process, multisite appearance management, etc.
Choosing Teams
This isn’t gym class; don’t be scared. This is, as stated before, mainly about accountability for the core team. In this cycle, anyone paired with a lead should hopefully be able to lead a pair/team in 3.5, and on and on, so we wind up with lots of experienced teams in the mix. For now, that list is fairly short, but if you are interested in having an official assignment or team designation:
As we divvy up leads and committers we’ll keep your request/offer in mind. If we haven’t seen much code from you, you might want to throw yourself into bug patches over the next week or two so there are some examples of how you approach core code available. Anyone not on a team can work on any ticket and/or bug, and can confer with the appropriate team or with Master Gardener Ryan Boren for assistance as needed.
Tentative teams so far: Nacin/dd32/Sergey on language packs, Mark/Pete Mall on multisite, Koop/ocean90 on wizard framework. People who already expressed interest in working with a team or making a time commitment: DH-Shredder, jkudish, helenyhou, drewapicture, MasterJake, tw2113, trepmal, japheth, sabreuse, jorbin, MarkoHeijnen, josephscott, maxcutler, aarondcampbell.
We’ll regroup next week to flesh out the scope.
Action Items
If you are interested in being on a team and/or making a time commitment, fill in this survey – all devs (@jane)
Figure out best time tracking solution – Jane, Nacin
Work out initial possible 3.4 features – Jane (1st draft from meetup notes), core team (catch any misses), everyone (brilliant additional suggestions) (@jane)
In case it escaped you, this is a pretty giant change from how we’ve done development in the past. It’s a risk. It could turn out to be the best thing we ever did, or it could crash and burn. Let’s all try our best to make it super awesome!
In the past, I’ve seen an interesting ticket or two in Trac and me/someone posts a patch but the ticket just lingers — never gets closed or updated or otherwise escalated, the patch rots. What’s the best way to drum up some attention for these kinds of tickets and get them closed out with some kind of resolution? http://core.trac.wordpress.org/ticket/10964 is a good example
In general, post to wp-hackers to get more community input on a ticket, drum up interest in the dev channel, etc. With that specific ticket, it comes down to scribu’s statement: “The status of this ticket is that there’s no clear data on which approach is best, only anecdotal evidence.” When that’s the case, tickets do usually linger until either one approach edges out the others or the bug is seen as growing more serious. We’ve talked about having a time limit on tickets, so that if something lingers too long it gets closed and we move on, but we haven’t come to any agreement on that yet. One step at a time, right?
Following your advice on your previous post i just wrote a mail to wp-hackers@lists.automattic.com updating two patch on two tickets. I am not going to subscribe to the list, just waiting for updates on related tickets.
I’d be sad to see anything like auto-closing. I have several tickets (All with patches) that I’d love to see in core, and to which there doesn’t seem to be much debate, but not much attention from anyone with the power to commit them either.
I’d love to see a dedicated bug stream in any release cycle to make sure we’re not missing out on the small changes that can make everyone’s life easier.
I’m happy to follow the bugs and update patches based on feedback etc. but I don’t have the time to follow wp-hackers I’m afraid – asking people to spend time reporting it there as well as in trac just seems like duplicated effort
[Although I accept that if there's a debate about an approach etc. to be had then it's probably a better place to do that than on a bug]
Don’t get me wrong – I know everyone is busy, and not everything can get done, I was merely arguing that auto-closing would be bad as stuff like this would get lost just because it wasn’t committed quick enough …
As always, using a thread about something else to call attention to a pet ticket is not recommended. “Bumping” with your own comment is also not great. Better to hop in dev channel and/or post to wp-hackers and get more people to comment on the ticket. When it’s one person and not more of the community, it’s less likely to get committed.
In tomorrow’s dev chat we will start discussing scope for 3.4. Note: we will not be talking so much about specific features/tickets as about choosing the unifying theme for the release and identifying what kinds of things fit under that umbrella. We’re still planning for the official cycle to begin mid-month.
The plugins directory should now update in near real-time. Previously updates only ran every 15 minutes and some other things (namely adding committers) fired less often.
Thanx for this info!
I have still problems with the date – this seems to only get updated “by accident”. I am using RapidSVN on Ubuntu Linux. Sometimes I have to edit readme.txt numerous times to get the new date and something absolutely nothing happens. This is annoying because half of my plugins were updated in the last days but it still shows all dates from December…
These are the notes from a breakout discussion on multisite at the core meetup with me, @markjaquith, and @nacin. As with all of these discussion summaries, please remember that they’re just discussions. I’m posting the notes for transparency purposes, not to say that these are the only things discussed or decided. I’m working from notes, and sometimes you don’t get everything down when you’re taking notes (next year I’ll record these things instead).
Multisite!
Who can lead this joint? Since the merge and Donncha moving on to other things, we had Ron for a cycle, Pete for a cycle, then no one. It would be good to have someone act as component owner.
Multisite needs parity with the single site experience. Includes UI, UX, copy/strings, install flexibility (subdomain etc), installation ease (add a site).
First we need to improve the manage/use experience, then fix install stuff and get it into the dashboard to turn on multisite.
We need a useful global dashboard.
We need to have flexibility in where sites and networks live — should be able to live wherever you want on one network. Subdomains/subdirectories/mapping/whatever you want, mixed subdomain/subdirectory, custom domains, global permalink consumer/router.
Need to fix different workflows: adding users to network, adding users to site, invitations. User signup, creation, assignment, invitation all need new flow
We need parity between plugins and themes. Enable vs activation is confusing, need to improve language, indicators. Need ability to network enable but disable for individual sites. Need to standardize network enable/activate etc for plugins/themes. Network activated plugins don’t show in individual site’s plugin list, which is confusing.
UX Action Items:
UX ACTION ITEM — Include network activated plugins in the plugins menu and give message that it is automatically on for the whole network (if admin/have rights to see plugins screen).
UX ACTION ITEM — Autocomplete usernames or site names for network admin and for superadmin everywhere.
UX ACTION ITEM — Get multisite tag/indicator on plugins in directory, add multisite specific/required indicator.
Under the Hood Action Items:
ACTION ITEM — Get rid of MS-FILES.
ACTION ITEM — Enable install in subdirectory so you can use externals.
Great; i love solutions with mutlisite and i wait now for an global dashboard; current i use the root blog (1) for this job. Great news
I wish the team mery christmas and really nice new year. Best regards
Good.
These are items that interest me.
An updated website (multisite), to version 3.3, and found some difficulty in managing permissions and what is accessible by users. It may not have found the right plugin. It aims to improve this item?
+1 Happy to help as time allows. I’ve been involved with and rolling out more and more Multisite installs… there’s definitely a lot of space for improvement.
Seriously, these are just notes so we talk about stuff, not features we are building.
Tom Lynch, 
Marko Heijnen are discussing. 
Lee Willis, 
Jane Wells 9:02 pm on January 25, 2012 Permalink |
Also, draft of teams page: http://wpdevel.wordpress.com/version-3-4-project-teams-and-status/