TLDR: Fewer bugfixes and support for the next week or two while we are focusing on making the site fast and stable. General shift in direction towards more stable and polished features over a large breadth of slightly buggy features.

It's been one week since the launch of the open beta. Since then we had some amazing posts, fixed tons of bugs, answered over 200 of your support questions on Intercom and added over 60 user-submitted issues to our Github. I think this week has been a good start for the new LessWrong, in large parts because of your continuous feedback and input. Thanks!

But despite the positives, and this became clear to us thanks to your input, there is a core problem with the site. LessWrong 2.0 is slow right now. Like, unbearably slow sometimes (I've experiences load times of 10+ seconds, which is totally unacceptable). This has probably caused many of you headaches, and has made the experience of using the site frustrating.

In addition to that, a good chunk of features are quite buggy. Sometimes when you create a post, it doesn't show up where it's supposed to, and you can't find it any other way than via a link. Or sometimes the page reloads and you lose all the things that you've written because we don't automatically save new posts and comments as drafts.

Here is a quick story of how we got to this state:

• Our top priority until now was to build an MVP that mostly has feature parity with reddit (so we can port over the data from the old site)
• We wanted to have a modular codebase that allows us to extend and change that functionality easily
• This means our development so far had been focused on developing features and getting the basic functionality going, not on making everything smooth and bug-free

And while it is tempting to continue to focus more on feature improvements and make the site more complete, I think it's time for LW 2.0 to focus its development on stability and speed. And only as soon as that has reached a high level, start expanding the feature set of the platform again.

This means, for the next few weeks, I and the rest of the team will do much less development on new features and focus much more on speed and the core user experience of a small selected set of features.

This might mean we temporarily turn off features on LW 2.0, if that is necessary to create a stable and pleasant experience.

To give you a concrete sense what this means for you, here is our current ordered list of priorities that we are going to be working on over the next few weeks:

1. Improve the content reading experience

To do do anything else on LessWrong you first have to read things, and the key to a good reading experience are fast loading times and good navigation. There should be almost no discernible load time when you click on an article to the new LessWrong, or when you navigate to different parts of the page.

I will be experimenting with a few different approaches to achieve this, but one of them will be to build a significantly feature-stripped version of the page that basically removes all features that are not strictly necessary for a good reading experience. If that works, I will then incrementally add features back to it, while ensuring that the core reading experience does not deteriorate at any step. Since I don't want to interrupt the flow of things at LesserWrong.com with this, I will be hosting that version of the site at LessestWrong.com instead. If you ever find yourself frustrated with the reading experience on here, you can check our progress on making the site fast over at LessestWrong.

2. Improve the core writing experience

Multiple people have mentioned that they lost content because the site reloaded while they were writing a comment or a post, or that some of their writing didn't show up in the place they intended. This is definitely not acceptable for the final version of LW 2.0, and fixing this is our second highest priority. This means building features like autosaving comments and posts as drafts, and making the navigation of a comment thread intuitive and fast. A secondary priority in this category is improving the writing experience on mobile, which we should be able to do relatively easily (mostly by just deactivating most of the more advanced writing features).

I currently see the comment-writing experience as more important than the post-writing experience, so that will be optimized first. However, all of this only becomes the focus after we fixed the performance issues.

3. Everything else

After I am done with these two things I will probably know more about what the next bottleneck for the page is. But until then, basically everything else will be deprioritized. This means I won't be focusing as much on bugfixes unrelated to performance, reading, and commenting for a while, and will generally delay bugfixes until I can solve an underlying systematic issue that is causing that bug and many others. The team will also hang out less on Intercom and provide less super-fast support until we have solved some of the more systematic issues.

I am interested in hearing whether anyone disagrees with this, and please feel free to continue to ping me and the others on Intercom or Github, even if we will be less responsive than previously.