Instead of Less Wrong being a project that’s no org’s top focus, we’re creating an org focused on rationality community building, which will have Less Wrong as its primary project (until Less Wrong doesn’t look like the best place to have the rationality community).
We decided a few weeks ago that the LW codebase was bad enough that it would be easier to migrate to a new codebase and then make the necessary changes. My optimistic estimate is that it’ll be about 2 weeks until we’re ready to migrate the database over, which seems like it might take a week. It’s unclear what multiplier should be applied to my optimism to get a realistic estimate.
So there will be the React-based UI, the Meteor middle layer, and some database (Mongo?) in the back? Who will host the server?
If you are already talking about migrating the database, do you have the front end pretty much ready, then?
You have to be careful about switching over with an incomplete feature set as LW isn’t terribly healthy and the transition shock might turn out to be very hazardous...
So there will be the React-based UI, the Meteor middle layer, and some database (Mongo?) in the back? Who will host the server?
Apollo/GraphQL. I expect us to pay a typical hosting company to host the server; it’s unclear yet who.
If you are already talking about migrating the database, do you have the front end pretty much ready, then?
Yes and no; Telescope’s core is already fully functional and has a roughly similar data structure to Reddit, and so we can move posts to posts and linkposts to linkposts and comments to comments. So that part of the migration seems clear, and is the sort of thing that Trike has already done before (in moving from Overcoming Bias to Less Wrong).
But our customized version of Telescope will probably handle them differently than the core does. Suppose, for example, that we want to move from Less Wrong’s html post creation to Markdown post creation, then we need to convert all the old posts (stored as html files) into Markdown source code for those files. And until we have the Markdown post creation the way we want it, it doesn’t make sense to actually code it.
You have to be careful about switching over with an incomplete feature set as LW isn’t terribly healthy and the transition shock might turn out to be very hazardous...
Yeah, I’m worrying about this. Switching before it’s better than current LW is bad; switching once it’s better than current LW is okay but might waste the “reopening!” PR event; switching once it’s at the full feature set is great but possibly late.
Yeah, I’m worrying about this. Switching before it’s better than current LW is bad; switching once it’s better than current LW is okay but might waste the “reopening!” PR event; switching once it’s at the full feature set is great but possibly late.
Perhaps switch once it’s as good, but don’t make a big deal of it? Then make a big deal at some semi-arbitrary point in the future with the release of full 2.0.
How about doing a public beta for a month or two, with a warning that afterwards everything posted on the new server will be deleted (including new user accounts, etc.), data from old server will be imported, the old server will become read-only, and the new server will become the official one.
Since you can embed Markdown in HTML, you might find that you don’t need to convert the posts.
It’s very possible that I’m confused here, or missing a cool technical trick. (And also maybe we should have separate Markdown and html editors, instead of forcing everyone to use one, which would also make it trivial to import all the old posts while still moving future posts mostly to Markdown.)
Is this something you need more people to help with?
More people would be appreciated! Email me for details.
It sounds like the original Markdown has some extra restrictions how you close the outermost HTML tag, but I suspect most parsers ignore that part of the “spec”.
I’m curious what plans you have re: open source accessibility on the new codebase?
It might be cool to get the minimum viable version up and running, with a focus on making the documentation necessary to contribute really good, and then do a concerted push to get people to make various improvements.
That may not work, but it’d be an obvious time to try for it.
Two notes on things going on behind the scenes:
Instead of Less Wrong being a project that’s no org’s top focus, we’re creating an org focused on rationality community building, which will have Less Wrong as its primary project (until Less Wrong doesn’t look like the best place to have the rationality community).
We decided a few weeks ago that the LW codebase was bad enough that it would be easier to migrate to a new codebase and then make the necessary changes. My optimistic estimate is that it’ll be about 2 weeks until we’re ready to migrate the database over, which seems like it might take a week. It’s unclear what multiplier should be applied to my optimism to get a realistic estimate.
I think it’s better to be somewhat separate from CFAR. CFAR has their own priorities, which could make LW neglected.
Oooh.
So there will be the React-based UI, the Meteor middle layer, and some database (Mongo?) in the back? Who will host the server?
If you are already talking about migrating the database, do you have the front end pretty much ready, then?
You have to be careful about switching over with an incomplete feature set as LW isn’t terribly healthy and the transition shock might turn out to be very hazardous...
Apollo/GraphQL. I expect us to pay a typical hosting company to host the server; it’s unclear yet who.
Yes and no; Telescope’s core is already fully functional and has a roughly similar data structure to Reddit, and so we can move posts to posts and linkposts to linkposts and comments to comments. So that part of the migration seems clear, and is the sort of thing that Trike has already done before (in moving from Overcoming Bias to Less Wrong).
But our customized version of Telescope will probably handle them differently than the core does. Suppose, for example, that we want to move from Less Wrong’s html post creation to Markdown post creation, then we need to convert all the old posts (stored as html files) into Markdown source code for those files. And until we have the Markdown post creation the way we want it, it doesn’t make sense to actually code it.
Yeah, I’m worrying about this. Switching before it’s better than current LW is bad; switching once it’s better than current LW is okay but might waste the “reopening!” PR event; switching once it’s at the full feature set is great but possibly late.
Perhaps switch once it’s as good, but don’t make a big deal of it? Then make a big deal at some semi-arbitrary point in the future with the release of full 2.0.
How about doing a public beta for a month or two, with a warning that afterwards everything posted on the new server will be deleted (including new user accounts, etc.), data from old server will be imported, the old server will become read-only, and the new server will become the official one.
Since you can embed Markdown in HTML, you might find that you don’t need to convert the posts.
Is this something you need more people to help with?
It’s very possible that I’m confused here, or missing a cool technical trick. (And also maybe we should have separate Markdown and html editors, instead of forcing everyone to use one, which would also make it trivial to import all the old posts while still moving future posts mostly to Markdown.)
More people would be appreciated! Email me for details.
Inline HTML is valid in Markdown:
https://daringfireball.net/projects/markdown/syntax#html
It sounds like the original Markdown has some extra restrictions how you close the outermost HTML tag, but I suspect most parsers ignore that part of the “spec”.
Do you know if you’ll be able to maintain their familial relationships as well?
We picked Telescope because it has a threaded commenting system, as opposed to systems like Discourse.
I’m curious what plans you have re: open source accessibility on the new codebase?
It might be cool to get the minimum viable version up and running, with a focus on making the documentation necessary to contribute really good, and then do a concerted push to get people to make various improvements.
That may not work, but it’d be an obvious time to try for it.
Like the current codebase, it’ll be hosted on github.