#AANDigital: WordPress in the Newsroom

Since I’ve been involved in the news industry, I’ve been a huge proponent of open source software. In particular, this selling point: open source makes for much easier cross-institution collaboration. Open source software provides a legal framework for companies to pool development resources, and build mutually-beneficial products. However, as I learned the hard way, news organizations need to get to the point where they’re comfortable managing their own open source software before any collaboration can ever happen. We’ve made some strides, but we still have a ways to go.

Today, I was honored to speak about WordPress in the newsroom to the AAN Digital Conference. The alt-weeklies industry is in a situation very similar to what I saw in college media a few years back: one proprietary CMS dominates, editorial workflow is MS Word to InDesign to web, and most of the focus is on print. It was a bit of déjà vu. Fortunately, everyone is also super enthusiastic about the web — no curmudgeons in the audience.

The WordPress-powered sites I highlighted: Quartz, Metro, CBS New York, Rolling Stones, Online News Association, and DigBoston. Quartz is near and dear to my heart because I think they’re really at the forefront of innovation with an app-like product and responsive design. I can’t wait until they roll out their commenting system.

Features and plugins I pointed out include: distraction-free writing, drag and drop media uploader, Edit Flow and WP Frontend Uploader. If you’re looking for more publishing-related plugins, we’re slowly profiling our recommendations in the VIP Plugins Directory.

One parting note: this conference was the first time I’ve heard “dry humping” as a recommended way to show your appreciation to the organizers. Keep on rockin’, alt-weeklies.

How you might “open source (almost) everything”

I’d like to identify ways in which Automattic can release more code as open source by default.

In the WordPress.com repository, there’s a fair amount of code in use that’s never seen the light of day. Bits and pieces of this code would probably be useful to other people, and subsequently be improved as more developers read, implemented, and found new uses for it.

Open source is a unique and tremendously important phenomenon because it enables people to create more economic value than they could with previous collaborative frameworks. It’s “one of the most important ideas of our generation.” Automattic as a company believes this too; on the first page of our internal company documentation, Matt Mullenweg says, “I’m fine with releasing basically any code on WordPress.com that isn’t our password files.”

However, we don’t release as much code as we could be releasing, nor do we go about many our projects in the open source way we admire. I get the sense others in the community may agree.

Part of the challenge, as I perceive it, is that we (Automattic) build new functionality for WordPress.com, are lazy in our implementation, and it then becomes extra work at the end to “release” the functionality as a plugin. People have limited time in the day, understandably, and the last step doesn’t get done.

Last month, I wrote an internal blog post identifying four ways I’d like to see Automattic improve:

  • Releasing (or mirroring) as much of the WordPress.com codebase as possible.
  • Building community around parts of WordPress.com infrastructure, both in terms of people who use it and people who develop for it.
  • Incorporating more third-party code into our codebase, and actively contribute back to it.
  • Modeling best practices for open source projects, including support and documentation.

There was good conversation in the comments and, in somewhat typical fashion, not a lot of clarity on the takeaways.

Personally, I’d like to get as much WordPress.com code into a repository that VIP developers can check out and use in their development environments. Hell, it even means they can submit patches for fixes, coincidentally as Erick Hitter just did while I’m writing this post. I’d like to move our existing, private shared plugins repository into a WordPress.com public plugins repository which would also contain code like the shortcodes we’ve implemented on WordPress.com.

Communication is the lifeblood to open source, and the only remedy to poor communication is over-communication. For an open source project, discussion should be public, ticketing should be public, and the changelog should be public. This obviously isn’t to say that everyone should have an equal voice — rather, everyone should have an equal opportunity to participate. Making public WordPress.com’s internal code would be a start, but that would just be the start.

What other approaches do you think we could take?

If you haven’t already, I’d highly encourage you to read Tom Preston-Warner’s “Open Source (Almost) Everything“. It’s legit.

Co-Authors Plus v2.6.3: Enhancements and bug fixes

Co-Authors Plus makes it easy to add multiple bylines to a given post, and has full support for custom post types. Out just a moment ago, v2.6.3 has the following improvements:

  • AJAX user search is back to searching against first name, last name, display name, email address and user ID. The method introduced in v2.6.2 didn’t scale well across hundreds of users.
  • French translation courtesy of Sylvain Bérubé.
  • Spanish translation courtesy of Alejandro Arcos.
  • Bug fix: Resolved incorrect caps check against user editing an already published post. Thanks to Doug in the WordPress.org forums for the help.

Please post any questions, bug reports, feature requests, etc. in the WordPress.org forums. If you want to contribute code, I’m eyeballing co-author management in Quick Edit and guest author functionality for v2.7.

For WordPress.com VIPs, this update has already been deployed to the shared plugins repo.

#techrakingcir: The Future of the CMS

Today, I’m down at Google in Mountain View at Techraking, a gathering of technologists and investigative journalists. It’s been super inspiring because of the fresh to me perspectives — I’d love to help Portland media outlets with projects like those I’ve heard about.

At lunch, I learnt I was to lead a small group breakout on “the future of the CMS.” To keep the discussion going, we started out by brainstorming the things we liked and want to improve our respective software, and then did a roundtable to identify our six month personal goals.

Some things people like about their CMS:

  • Drupal done well is easy to use; there are a ton of modules
  • Affordability, open source is cheap
  • Community to work with
  • Many different homepage templates to choose from depending on the stories of the day

What people would like to improve (lots of conversation, as expected):

  • Data portability
  • More headless; produce output other than HTML
  • Scalability, faster when many people are working in the admin
  • Less steps for completing common, simple tasks
  • Integration with story budgeting, calendaring; API for story flow
  • Magical WYSIWYG editor; auto-save that works; track changes
  • Support structured data / semantic markup
  • Customization for story layout
  • Small pieces loosely joined; better integration with other services

Given the short notice, I thought the breakout session went quite well. About twenty people showed up. In terms of what worked:

  • Small group discussion; knew enough backgrounds to call out different people to talk
  • Noted salient points on the whiteboard as a way of plotting direction
  • I enjoyed the “what are you going to work on in the next six months” takeaways at the end

Next time, we should:

  • Figure out the location ahead of time so we don’t waste time finding it
  • Have people introduce themselves if they haven’t spoken yet
  • Every fifteen minutes, have something for everyone to participate in so people don’t check out

Co-Authors Plus v2.6.2: Enhancements and bug fixes

Co-Authors Plus makes it easy to add multiple bylines to a given post, and has full support for custom post types. Out just a moment ago, v2.6.2 has the following improvements:

  • AJAX user search matches against first name, last name, and nickname fields too, in addition to display name, user login, and email address.
  • Comment moderation and approved notifications are properly sent to all co-authors with the correct capabilities.
  • Filter required capability for user to be returned in an AJAX search with ‘coauthors_edit_author_cap’. This defaults to ‘edit_posts’
  • Filter out administrators and other non-authors from AJAX search with ‘coauthors_edit_ignored_authors’
  • Automatically adds co-authors to Edit Flow’s story budget and calendar views.
  • Bug fix: Don’t set post_author value to current user when quick editing a post. This doesn’t appear in the UI anywhere, but added the post to the current user’s list of posts. See related forum conversation.
  • Bug fix: Properly cc other co-authors on new comment email notifications
  • Bug fix: If a user has already been added as an author to a post, don’t show them in the AJAX search again.
  • Bug fix: Allow output constants to be defined in a theme’s functions.php file and include filters you can use instead.

Please post any questions, bug reports, feature requests, etc. in the WordPress.org forums. If you want to contribute code, I’m eyeballing co-author management in Quick Edit and guest author functionality for v2.7.

For WordPress.com VIPs, this update has already been deployed to the shared plugins repo.

New York Times releases code to help journalists collaborate on WordPress, other platforms

New York Times releases code to help journalists collaborate on WordPress, other platforms. Track changes within the WordPress editor. Code is available on Github; it would be awesome to see this support realtime collaborative editing too. (via Steve Myers)