photomatt

dorchadas, we haven't been able to track down your account, but if you get in touch with help@WordPress.com and link to this thread, would love to debug the slowness with you, and also happy to comp you a 300/year business account which supports plugins and themes for 3 years.

Do you have any plugins, maybe a SEO one, that may be active?

Core Gutenberg should be super fast, we test it with Wait But Why posts. But a plugin could be adding some sort of loop that's slowing things down.

WordPress itself.

You don't need legal approval to do dog walking. If you got that impression, we obviously need to be better at communication.

I don’t want folks to get too hung up on the 25/hr number, it’s not meant to be a negotiation or imply a salary — in fact it’s identical for every role at the company, whether you’re doing a trial project in support, engineering, or to be our new CFO. At the time when we introduced it other companies were having candidates invest a lot of time to get hired with zero compensation, which didn’t seem fair and we wanted to shift that. You can also compare 10-20 hours of a remote trial to the time spent flying to and from a city, being there for a day, and doing lots of on-site work and interviews.

Howdy, Automattic CEO here. The trial is meant to be mutual, so both sides get a realistic idea of what it’s like to work together.

I would say that how we work now 1 month is on the outside of how long I want the entire process to take, from application to offer letter. So that means the trial project can be a lot shorter.

People come in from all sorts of situations in terms of when and how they can participate, the key there is just communication. The team is very flexible in tailoring the process to be inclusive of different time restrictions people may have.

Finally I’ll just say as someone who used to be deep in the code and systems myself as WordPress and Automattic started and scaled, one of my favorite things today is seeing the impact new engineers joining can have on products and teams that impact large swathes of the web. If you’re curious at all about working with a fully distributed company with open source deep in its ethos, please drop in an application and come meet our folks. I’m always happy as well to exchange DMs or hop on a quick call to talk about our opportunities.

Adobe must have the best salespeople ever, for what people pay for Experience Manager vs what it actually does.

I would love for that percentage to go up, and we are hiring! High velocity and high scale backend work, tons of React with Calypso and Gutenberg, the most leveraged systems group I've ever seen, a really lovely-to-work-in native apps team, and of course everything coming in with Tumblr.

You will know, because we announced it. :) It's 100% primary. There's been a lot of additional interest so probably more secondary in the future.

I hope that our fundraising history shows we wouldn't do a round that reduced our business optionality in the future!

Where it's possible, I'll always invest in product and engineering over marketing (specifically external ad spend). The Tumblr acquisition is a good example of that, we actually scaled back WP.com marketing in anticipation of that to give more room to bring on Tumblr's entire 200ish-person team. 90%+ of our growth is organic, and that percentage is going up.

We have one! https://developer.wordpress.com/docs/firehose/

We've found the model of strong CEOs or GMs, combined with a great culture and shared platform, can be really magical. It doesn't need to be complicated, but it's also not easy.

That's an excellent question! I don't want to be so presumptuous as to define an exact approach before the technical exploration has started, besides saying it'll be done incrementally and in an easily revertable way to be invisible to users, just like the big datacenter migration Automattic just completed a few weeks ago.

At the point when we start this the Tumblr team will have been part of Automattic for the better part of a year if not more, so there will be a lot of learning and evolution of the products on both sides to make any migration easier.

I promise we'll write about it afterward for anyone who is curious.

Thank you — the combined teams will do our best to make your optimism deserved.

I can imagine that false positives are incredibly frustrating for legit creators, and something we will try to eliminate.

Automattic has had offices in the past, so there is some precedent. The Tumblr team has a strong office culture, so we don't want to break anything that's working well. Simultaneously we believe the future of work is distributed, and over the next decade that's the direction we firmly want to head. If you want to learn more about this, including hybrid organizations, check out my new podcast at distributed.blog.

We are planning to do the opposite: excited to invest into the platform. The web needs open and independent publishing and social media more than ever.

Adult content is not our forte either, and it creates a huge number of potential issues with app stores, payment providers, trust and safety... it's a problem area best suited for companies fully dedicated to creating a great experience there. I personally have very liberal views on these things, but supporting adult content as a business is very different.

I'm super excited to have the Tumblr team and product join the Automattic family. We've been evolving Automattic to be more of a Berkshire Hathaway-inspired model and businesses with a lot of autonomy, and this continues that trend.

I was very impressed with the engagement and activity Tumblr has continued to have, and I hope that with this new ownership and investment the product will blossom.

That article is now two months old and a lot has changed and improved since then. You also have to compare apples to apples: don't just compare writing in a single text area to manipulating complex blocks, try to accomplish the same task (like putting two captioned images side by side) in both interfaces.

We had it as an extension for a year and a half, and in that time it became the fastest growing plugin in WP's history. User tests also showed significant issues with our current editor approach and much better results with Gutenberg enabled, that's why some hosts have had it on by default since the summer.

I agree it's not for everyone, that's why there's an opt-out, but it is an improved experience for the vast majority of current and potential future users. It's shipped, and now we can continue to iterate on it.

Since Jetpack code is also what we run on WP.com (tens of billions of pageviews) it goes through a huge amount of performance tuning and optimization. The way modules work when you turn them off they don't have any overhead, similar to turning off a plugin. If you were using literally one thing it might feel like a lot, but as soon as you use 2-3+ things Jetpack does it's a lot more efficient than separate individual plugins to accomplish the same task.

Check out Jetpack, it can auto-update all your plugins, and has a "Rewind" feature with real-time backups so you can one-click take your site back to a previous state if anything didn't work.

I completely agree that growth is a result, not a goal in and of itself. Fundamentally it represents what people, given the open market of all possible solutions to their problems, choose. We want to create the best software experience because that will help people choose Open Source vs proprietary solutions, which even if they don't appreciate it at the time will be better for them and the web overall in the long term.

Thank you for recognizing we were willing to walk away from React because of the license. It was chosen because of technical merit originally, but was a day or two away from delaying the entire project 6+ months to refactor.

AMP is interesting but no decision has been made there yet.

Thank you for sharing your thoughts and a generally excellent comment.

The best read about Accessibility in Gutenberg is here:

https://make.wordpress.org/core/2018/10/18/regarding-accessi...

Accessibility has been thought about from the beginning, and no design happened behind closed doors (it was kicked off and announced at WCUS 2016), but we are doing a fundamentally more complex task with block manipulation.

I'm not sure what the best path forward is there. We'll continue to make the block editor friendlier to accommodate accessibility needs, and I also think it's important that WordPress has a variety of ways to post to it, from email, to other apps, to the command line... by supporting as we always have a ton of ways to get content in and out of WordPress it'll allow people to use the interface they enjoy the most.

Blocks need not do that, and most should be no more overhead than what people were already doing in posts. Perhaps is a big focus though, but one that's been easier to address outside of core with things like expanded CDN support in the latest version of Jetpack Photon.

We're definitely working on making it more efficient, and will continue to. We tested with WaitButWhy posts that are 50k+ words. In the old WYSIWYG it wouldn't even load, Gutenberg can parse and load it in a few seconds.

There's also facts: Gutenberg plugin adoption is growing faster than Classic Editor adoption, so it's not likely it will have more active installs than any other plugin. But even if it did, that's okay, we're supporting it. It's not a failing of Gutenberg, just showing that people for whatever reason don't want change.

AFAIK there is no change to database or memory usage post-Gutenberg, especially since pretty much all of the new code executes on the client side when you edit a post. It may use more memory in your browser, but not anything that should cause issues.

+1000