For today’s dev chat, let’s check in on how we’re feeling about a beta 2, any blockers we might be seeing, and then do a scrub on tickets, particularly focusing on things that can be committed or punted. Please add any other agenda items in the comments.
Tagged: agenda Toggle Comment Threads | Keyboard Shortcuts
Proposed agenda for today’s dev chat. We’re targeting the late evening Eastern US time for beta 1.
Proposed agenda for today:
- A look at the assignments from last week – next steps, any stucks, any needs. (@azaozz,
- #27423: Improve Media Modal UI at small-screen sizes
- #14759: Improve the way oEmbed deals with caching (@markjaquith)
- #20564: Framework for storing revisions of Post Meta (@adamsilverstein)
- How are we feeling about beta?
Please add any items you have in the comments below.
Agenda for today’s dev chat:
- Beta timing – on schedule for next week, 7/2.
- Organize and rally around pushes on features: oEmbed, i18n, plugin install experience, media grid.
- #22023: Remove UNIQUE for slug in wp_terms.
Please propose other items in the comments below.
For today’s dev chat starting shortly, let’s:
- Do a quick check on any of the bigger features for resource needs or sticking points (media grid, i18n, plugins page, oEmbed).
- Talk about shared terms.
- like_escape(): #10041.
- Do an open-ended bug scrub, building on the momentum @wonderboymusic kicked off with commits and this post. Will guide these with specific reports to be linked in dev chat.
Other proposed items:
- 3.9.2 status.
Add yours here below.
Proposed agenda items for today’s meeting:
- State of .org APIs for plugins and i18n (@tellyworth and @nacin), where people can help with tickets, storyboarding, or otherwise.
- Taxonomy roadmap: #17689 needs active discussion, please.
- Media grid: #24716
- oEmbed sandboxing: #28249
Add anything in comments below.
Summary of 5/21 dev chat (IRC log):
- Posts like the i18n goals one serve as a great model for anybody who has ideas for a feature or component roadmap, whether that’s within one cycle or longer term: a list of concrete goals that can be divided up into specific tasks.
- The make/* blogs should be used as much as possible for discussions and progress updates. Teams that have been using separate P2s but should consider using the make.wordpress.org instead for wider reach and more active participation from the community.
- Keep in mind that plugins are supposed to encourage rapid and possibly wild experimentation – please do not discourage that.
- Think of meetings as blocked out times where you can more reliably get a group together and get unstuck as needed, but we should take advantage of async (Trac, P2) and adhoc (IRC outside of meeting) discussion as much as possible.
- i18n goals for 4.0 have been posted, @nacin is seeking people to help with a lot of it. @yoavf, @kovshenin, @iandunn, @coffee2code, and @otto42 have done or will do some of the i18n tasks.
- JSON REST API was given another week to collate a detailed compare-and-contrast with the other available APIs, including the JSON API plugin and Jetpack/.com’s API, and proven client implementations.
- Media Grid has a narrowed scope for 4.0 inclusion: something more visually driven than the standard list table, much like theme browser brought to themes and is being investigated for plugins in 4.0. Will also fix some long-standing issues that were brought in with 3.5.
- Editor improvement ideas: @markjaquith and @avryl have put together a proof-of-concept plugin that we should smooth out and make a decision on.
Agenda for 5/28:
- Make final decision on JSON REST API.
- One sentence updates from various groups – i18n, media grid, plugins, oEmbed, etc. Come prepared.
Please propose any other agenda items in the comments below.
Proposed agenda for today’s dev chat happening shortly:
- One line updates on where things are from various teams
- Review of feature plugins (any ready for 4.0?)
- Other business – please add any thoughts in the comments below.
- Bug scrub of 4.0-early
Please propose agenda items for today’s dev chat at 20:00 UTC (just over an hour from now).
In particular, we should discuss script handling with embed wpview representation. See #28195. Let’s also do some quick check-ins with working groups and feature plugins. Decision time for plugin inclusion is next week.
We’re having a dev chat about Multisite in #wordpress-dev tomorrow (May 14, 2014 18:00 UTC). I’d like to split the chat into two main areas:
- Open vs. closed networks
- Everything else
The concept of an open network where users can create their own sites was the popular impetus for WordPress MU, but is decidedly not the primary use case for multisite anymore. Most operate closed, trusted networks, where site signups are disabled (and often user signups are disabled as well).
Back in October, Andrew Nacin published a collection of thoughts on potential changes to Multisite, one of which was the idea of open vs. closed networks. I’d like to discuss this concept and whether now is the right time to tackle it. Here are some relevant paragraphs from that post:
When a network is not designed for “open registration”, there are a number of undue burdens that should be lifted for administrators. Uploadable file types are severely restricted, and the amount they can upload is capped. They cannot activate installed plugins, though there is an option for this. They cannot add users to their sites without knowing their email address (ostensibly to prevent spam), and the user must still go through a “confirmation” process. New sites must go through an “activation” process. They cannot create new users.
I don’t think WordPress needs to decide that the multisite feature is only geared for closed networks. Rather, a single option — set on install, and controllable via network settings — can control this entire paradigm very effectively.
Essentially, I am proposing we trust single-site administrators in a closed network to not be spammy, and to be given wide-ranging control of their own sites; but that we do not extend that trust to important areas of security.
So, let’s discuss whether now is the time to introduce the concept of open vs. closed networks, what form it takes, and to which functionality it extends.
- What differences should we see between an open network and a closed network?
- Open user registration
- Open site registration
- Capabilities for regular Administrators (plugins, themes, users)
- Email notifications (amount of, and wording in)
- User listing and user editing UI differences
- Site listing and site editing UI differences
- Network admin dashboard UI differences
- What form should the open vs. closed network option take? A UI option when installing multisite? Changeable after the fact or set in stone like subdir/subdomain option?
- What changes need to be considered for existing multisite installs?
Secondly, let’s discuss all other multisite improvements that we would like to see. Several may well be related to the idea of open vs. closed networks, and that’s ok. Here’s a list to get us started:
Reignin notification emails when adding sites, users
- Improve user searching – #27304
- Improve user management
- Better explanations for what archive/spam/delete does to a site
- Merge in the Hyper Admins plugin
- Merge in the User Management Tools plugin
If anyone has particular issues they’d like addressed (bonus points for existing tickets on Trac), leave a comment and we’ll see what we can cover.
Two other items worth mentioning are:
- Domain mapping
- SSL improvements
I don’t think we’re yet at the stage where we could consider implementing domain mapping in core. It has a prerequisite of removing the subdirectory vs. subdomain paradigm, and we’re not near approaching that (unless someone wants to step up).
Regarding SSL improvements, I’m planning on arranging a separate working group to tackle a whole raft of SSL improvements in core that aren’t just related to multisite. I’ll be publishing a separate post in the next couple of days to get us started.