I lit a communication fire

Today I inadvertently lit a fire during the weekly WordPress core development chat by mentioning a Skype chat that had been set up and thus far been used to say hi, link to a Google Doc, and alert five people to an IRC meeting. I’ve included the full transcript of the chat from beginning to end at the bottom, because I do value transparency. I’m telling you now that some of my messages sound meaner than my intent – that is, after all, what happens when I didn’t originally anticipate being held openly accountable for them. I also am often typing with a baby in one hand who’s struggling to mash keys and 15 other chats open, though that’s no real excuse, because I am generally very direct, anyway. Everybody else sounds like a decent human being :)

Communication is hard. Everybody has a different style, and a different vehicle that best fits that style. When it comes to communicating within WordPress, especially with people I don’t know or have only met once or twice, I have two general thoughts: one, that it’s better to over-post something in different places (of course, preferably with one canonical post and the rest linking back to it), and two, that it’s important to find ways to marry different avenues of communication in order to include as many voices as possible.

The latter is difficult, and often I think to myself that it’s rather idealist and perhaps impossible. However, I see this in WordPress core and plugin development often: we have scheduled IRC chats, impromptu IRC chats, posts to a P2 with asynchronous discussion in the comments, Trac tickets with patches and comments, private pinging on Skype or HipChat or text message, using GitHub for developers and WordPress.org for users. Many people view this as a negative splintering of discussions, and I agree that if they are not interconnected and used appropriately, it can be. But I believe that with a little effort and pruning, we can make it work. I may be very much alone in this – disclaimer that this is my own opinion, etc. etc.

In Matt’s State of the Word at WCSF 2013, he revealed that the group working on the admin redesign plugin known as MP6 used a Skype group chat for a lot of their communication. I had the same initial reaction as many: “ugh, that sucks, it’s a closed loop and they’re making people feel like they’re excluded from the cool kids’ club.” While I still feel that way in some respects (and for full disclosure, yes, I was later added to the chat myself and promptly lit into something I didn’t like), I challenged myself to see the positives instead: that the group could now include people who had a hard time with IRC for one reason or another, messages sent while somebody was offline could be received as opposed to retrieved, and that without the pressure of knowing conversations are public they were able to be more direct and critical with discussion and feedback, especially when it came to design itself. We say code isn’t personal, but design is a different skill and feeling entirely.

I don’t enjoy spending my energy figuring out best communication channels, and people as a whole tend to feel more comfortable when there are parameters. Therefore, I am glad that in today’s instance, we’ve scheduled a weekly chat in IRC that appears to work for those who have voiced a desire to be actively involved in this particular initiative (bringing even more goodies to the media modal and TinyMCE). Perhaps the Skype chat will fade away, or perhaps we’ll discover that it serves as a good way to notify those who tend to have only Skype open that an IRC chat is scheduled or an impromptu one has broken out. I think it’s important to be open to these discoveries, and I value the chance to be more inclusive over accusations of being exclusive.

I also find it important to keep up with regular summaries on more static communication platforms like a blog/P2. IRC transcripts can be hard to read and parse, and commenting on them after the fact is awkward. This is also important for those who can’t make it to a chat – no time is perfect across all time zones, and people have life things happen, like getting sick or having an appointment or putting family first. I myself am especially empathetic toward those who get called away without much warning, and very much value the ability to consume and respond to information at my pace when needed, rather than that of others. I am very guilty of putting off writing summaries when I am in charge of them, and want to continue to work on bettering myself.

I sat here for a while pondering how to write some sort of “conclusion”, and I guess it’s this: I’m happy to cop to making a error in judgment earlier that led to me sending a message that I probably knew would not go over well, and I think it’s important to see these struggles as learning opportunities and use them to continue to make things better. I also think we should just go ahead and admit that sometimes real ideas come out of being dumb in private with somebody you’re friendly with – we have the .wp-core-ui scoping class in core because I responded to a text message bemoaning the bleeding of the buttons CSS on the front-end with (and this is a direct quote) “f*** it, let’s add the .wp-admin class!” I was kidding at the time, but he saw how it could actually work, and so far it’s been great. Perhaps especially because I relayed a censored version of the exchange later in IRC. :)

Skype transcript as follows.

Continue reading

MP6 + UI components

Going to just blog what’s on my mind/docket. Open source my brain or something.

Since I started contributed to core, I’ve thought about how we need to have UI components in core admin CSS (and used whenever an API outputs something in the admin). In 3.8, I would like to tackle Trac tickets #18909 and #16413. First, though, we need styling, and I think MP6 is a great place to do some rapid iteration.

In MP6, I’ve started a little initiative that serves several purposes – I call them test pages, and the intent is for them to serve as visual unit tests as well as the backbone for a style guide / UI docs. They’re hidden – to turn them on, define the MP6_STYLE_GUIDE constant to true somewhere, probably in your wp-config.php. These will definitely not become a part of core; when merge time comes, they would get split off into a separate plugin.

As of this writing, all you’ll get is a new top level menu item for a style guide, with one child page that serves up jQuery UI components, using their standard test page. It enqueues CSS from Google – namely, Smoothness, so it doesn’t look MP6. Yet. The goal (and this is open to anybody who wants to contribute) is to re-style jQuery UI components into something that looks and feels like WordPress+MP6. There are some technical considerations that probably have to be made – namespacing to avoid conflicts, possible conflicts with styles already in core/changing those places to use new styling, how styles are loaded and how color overloads work. But first: it needs to look and feel good.

Next up is a form test page. I’ll be using a few things as inspiration for the HTML: UIKit, Bootstrap, and perhaps Gumby Framework. I’m open to other suggestions as well. We’ll want to make form styling reusable (of course) and responsive. I’d love it so that no extra classes are needed when creating your extensions – forms “just work”, whether on a settings page or in a meta box. The test page should probably account for these various typical places of use.

There are lots more components we can look at over time – it perhaps shouldn’t be as thorough as a front-end framework like Bootstrap, but if we’re talking about refining WordPress as a platform, it needs to apply to the front-end side of building, too. Let’s just make sure we keep our eye on the iterative prize.

Admin CSS back-compat possibilities

I continue to think about CSS back-compat, especially as we dive deep into the land of MP6. Given that we are talking about build processes as well, I had an idea. There are two steps to this idea: a section (or separate file, if/when we get into building concatenated/compressed CSS for core) for CSS that is being kept for backwards compatibility. Things would generally stay for a cycle or so, but subject to evaluation in some cases for history and wide usage, such as settings tables. After that cycle, rules would move to a deprecated.css that is registered but not enqueued – if a theme or plugin needs it, they should enqueue it on applicable screens.

This is all just an idea – I don’t know if there would be hard lines about how long CSS stays in back-compat or deprecated areas, or if this would even work at all. I have no idea if we could or should throw notices somewhere (console?) like PHP can, and now jQuery with jQuery Migrate. Thoughts?

Scared of WordPress Core Trac, but want to give it a shot? Try Trac Gardening!

For 3.7, the biggest goal (at least in my mind) is to blow through Trac and close as many tickets as possible, either through committing a patch or because they aren’t relevant anymore. At close to 3800 open tickets, Trac just isn’t manageable for anybody anymore (except perhaps for Sergey). Casual and hopeful patch contributors are understandably intimidated and lost. Nobody wants to make a duplicate, and keywords often don’t accurately reflect the state of a given ticket, leaving people wondering how they can see tickets that need a body. We need to get this under control.

I consider Trac curation to be one of the most important but often overlooked areas of contributing to core. Other projects formally recognize them – for instance, Joomla! recognizes active members of their Bug Squad. There are efforts currently under way within WordPress to form core component teams, so I don’t currently have any real thoughts on what should be recognized and how, but I think something similar could be really nice.

In the community, some trusted contributors are given Trac privileges to do what’s called bug gardening. There isn’t really a whole lot about this that is different from what everybody else can do – it’s pretty much just that you can set the Milestone, which serves two purposes. One is that it prevents creep (of course everyone would want to put their pet ticket into the current milestone), and the other is that tickets that are closed still get some kind of review from somebody who’s been around, because the milestone needs to be cleared.

You don’t need to be given a little piece of Trac permissioning to do gardening, though! There’s a page in the handbook about bug gardening, but I thought I’d give a practical example based on how I do things. I’m sure it won’t work for everybody, but if it helps anybody, then it’s worth writing down.

I subscribe to what’s known as the Trac firehose: the wp-trac mailing list. It’s definitely not for everybody, and soon (seriously, soon) you’ll be able to subscribe to just certain components instead. However, I’d recommend that everybody give the firehose a shot, even just for a week or so. There are definite swings in activity, and I think it gives a great perspective as to the sheer number of tickets, comments, and patches that are clamoring for attention at once. If getting emails for when somebody is just cc-ing themselves to the ticket drives you insane, I have a handy Gmail filter for that: “added — Ticket URL:” → Trash. If you’re just doing it as a temporary thing, though, you might not want to filter those out. It’s a great barometer as to the level of interest in something, and it can often bring an old ticket back up for attention.

I try not to read these emails all day, but rather set aside a little bit of dedicated time to read them in chunks. I do make an effort to read everything, but if I’m overloaded and there’s a super active discussion on something I’m not tied into, like say using PDO, I might just delete it without reading. If I see something that’s been closed but the milestone hasn’t been cleared, I go check it out. Usually it’s been closed for a perfectly valid reason, like a duplicate or that it’s a plugin at fault, so I just clear the milestone and go on about my day. Other times I reopen it, or it sends me on a hunt for other duplicate tickets that can also be closed, etc. I might also add keywords if they’ve been left out when somebody adds a patch (has-patch) or somebody reports that a patch doesn’t work (needs-patch).

Many times, though, just seeing an email for a ticket triggers me to want to know more about it, and it often ends in a patch. As an example, take #17201: “dynamic_sidebar performance”. I saw that a newer gardener had closed it saying he didn’t see a performance issue, and the ticket title was vague, so I went to see what it was about. The complaint was that sanitize_title() was slowing things way down, and given that it’s something I’ve dinged people for using on display due to its heaviness in various code reviews, I thought that the ticket was probably perfectly valid after all. So I took a quick look at the function, saw that the usage of sanitize_title() is indeed there (and more than once in a call!), couldn’t reason out why exactly it’s even needed, and reopened the ticket with a comment saying as much. Now, I still haven’t figured out why it’s there, but it seems to me that a less expensive function could be used in its place. Maybe I’ll patch it. More likely, though, I’ll encourage somebody newer to patch it for experience. :)

There’s life beyond the firehose and messing with keywords and milestones, too. Reproducing bugs and testing patches in general are a huge help. There are various reports in Trac that can get you a picture of what’s going on in a given area – the most common ones people look at are 5 and 6 for the current release. You can also just pick a random open ticket, or look at a component, and go from there. If a bug report is just sitting there without any further comment, try reproducing the bug. If you can’t, ask the reporter for feedback (and leave the reporter-feedback keyword). If you can, leave a comment with the steps you used, as it helps for history and for further patch testing. From there, if so inclined, you can try writing a patch.

If a patch exists already, test it! If it doesn’t apply cleanly, you can mark the ticket with the needs-refresh keyword, and/or go ahead and refresh it yourself. If the patch doesn’t work, or doesn’t solve everything, leave a note saying so and add the needs-patch keyword. You can also, of course, iterate on the patch. If everything’s good, leave a comment saying that the patch works for you. If it’s a complicated process to testing the patch, it can help to leave your steps, much like with reproducing the bug in the first place. Refreshing and iterating on patches get you props just like a patch you wrote all on your own, so if the props are a good carrot for you, that’s something to note.

Don’t be afraid to do something “wrong”. Really, there is no wrong. Maybe somebody will reopen a ticket you closed, or maybe it’s not really a duplicate after all, but it’s not a big deal. Don’t take it personally or worry about it. Learn from it if there’s something to be learned, and keep going. Let’s clean up Trac, y’all.

WordPress 3.6 + Audio/Video

Originally posted on Scott Taylor:

Screen Shot 2013-08-01 at 1.39.43 PM

I have already written once about the new support for Audio / Video in WordPress 3.6:
http://make.wordpress.org/core/2013/04/08/audio-video-support-in-core/

I also spoke about the new features in my Code Poet interview:
http://build.codepoet.com/2013/07/18/scott-taylor-interview/

I wanted to use this space to give the users some information about the new code and how to take advantage of it.

Upload Limits

A lot of Apache / PHP installs have an arbitrarily low file upload size limit set (usually 2MB). An average .mp3 file is at least 3-5MB. Video can be way bigger. If you are on a shared host that doesn’t allow uploads over a certain size, you may have to get more creative about where your audio and video files are stored. The only difference will be not having them in your media library. You can use all of the new a/v features with remote files.

If you have access to your own…

View original 647 more words

Happy 10th, WordPress, and thanks from my little family

I talked a bit about how I got into WordPress in my CodePoet interview back in January, but what I didn’t say is that my whole family (well, the little one wasn’t born yet) is thankful for our favorite open source software project. My husband uses it for his website and photo blog, and loves being able to update and create his own content. I love that he’s so happy with the iOS app and Quick Photo posting with a dash of IFTTT for Facebook sharing – no Instagram or other non-self-hosted services for us. Our son will benefit from me being at home the majority of the time, as WordPress has allowed me to find a job path where I can work from home and be flexible to accommodate the needs of a family. He also looks dashing in his brand new purple W logo onesie, and has some special light blue ones from his name-twin to look forward to when he gets bigger.

I’m thankful for the friends I have made through the community – people who are infinitely smarter than I am and see things in ways I would never have imagined, and real friends I can get together with and not talk shop with if we don’t want to. I’ve also gotten to travel more than I ever thought I’d want to and am learning to get over bouts of imposter syndrome to say “yes, I am good at what I do, and I’ve earned my place in the world of WordPress”.

So thanks, WordPress, and congratulations on 10 years from the whole Hou+Sandí family :)

Sandís on WP10

Aside

I say this from time to time in conversation, thought I’d drop it here:

I love WordPress. I develop using it for my job and for my own projects, I write (occasionally) using it, and I suggest it as a tool for content-based websites all the time. I also hate it. If I thought WordPress was perfect just the way it is, I wouldn’t work on core. It’s the love that gets me through the ಠ_ಠ moments and drives me to want to see if I can do something about it beyond idle complaints.