I must agree with you that there are a lot of dealbreakers for me there. But it’s interesting to see what goes into deploying & maintaining the website.
I do think that if you guys refactor it, it might be quite nice to put a “generic” version of it out there, including some instructions like these for people that want to run it. There’s a lack of well-executed open source community platforms at the moment.
This one may be messy and not the most efficient or prettiest in terms of the underlying code, but the user experience is one of the most polished I’ve ever stumbled upon.
...
The phone bit I find surprising though since in my experience I’ve had issues with LW on my laptop but on my android, it runs really smoothly (latest stable firefox on both). But I guess it depends on a lot of factors and “run smoothly” is rather subjective after a point.
There’s a lack of well-executed open source community platforms at the moment.
Yeah, I strongly agree with this. There is a reason why we ended up building this one mostly from scratch, really none of the other options seemed very good.
I do think that if you guys refactor it, it might be quite nice to put a “generic” version of it out there, including some instructions like these for people that want to run it. There’s a lack of well-executed open source community platforms at the moment.
Not directly an answer to this suggestion, but I’ve definitely been considering spending a month or so packaging up what we have so far, and selling hosting + support for it as a way of financing the LW team and getting us more financial independence. That would also have the side-effect of having everything more nicely packaged up for other people like you to run their own versions. But I don’t really know what the demand is, and I am worried it would make us a lot more hesitant to do small hacky one-off things that make sense to have on LessWrong, but don’t make sense to have for all of our other users (like the annual review system).
Would it be possible to split the current website into “core” (what other people might need) and “plugins” (currently one: the LW and EA specific functionality)? Each plugin could have its own tables, its own pages, and inject some HTML code into specified places in the “core” (or other) pages. The plugin support should not cover all hypothetically possible cases, only what is needed to make the current “plugin” run.
I agree that thinking about how changes might impact other users makes development (and release management) way more complicated. Would probably need separate “stable” (bugfixes only) and “experimental” branches.
But I find it interesting, how many people want to have online debates, and how much the existing solutions suck. I already gave up the idea of hosting my own web forum, because it seems like it would become a full-time job to moderate and fight spam—and the choices are whether the “full-time job” would consist of developing and maintaining my own solution; or learning how to use an existing one, updating it constantly because every two weeks there is a critical security update, and coding my own plugins to fix or add functionality anyway; I am not even sure which option is less work in long term. This is really not good.
It’s possible, but I really expect it to be a lot of work. We have a lot of shared UI and small interleaving pieces of functionality all across the site, and I expect this would cut off a lot of the design space we could explore, or basically just force everyone to run the whole forum anyways.
Like, we modify the code responsible for displaying post-items during the review to display the small “Review” button on the right. I don’t know how to factor that out so that you don’t even get that piece of code shipped, and these kinds of dependencies are all over the place. The comments UI depends on moderation guidelines in subtle ways, the recommendations for the frontpage depend on your view-history, but I would also like it to depend on your comment and vote-history, and this would become harder where everything is plugin-structured.
The visual design philosophy of the site is also very much centered around minimalism and trying to only present you with the information you really need in any given moment, which often leads to small design changes based on context that I find hard to factor out (contrast this with the usual PhPBB forums that tend to just throw small independent widgets everywhere in order to customize your experience, leading to what I experience as massive information overload, but having the benefit of being much more modular and you can easily turn off whether you display the last-commented time of a thread, or the total number of comments, or the total number of contributors, etc.).
we modify the code responsible for displaying post-items during the review to display the small “Review” button on the right.
This is exactly what I imagined. Each plugin would have a function “insert my code” with two parameters: first would be the name of the place (in this case e.g. “article widgets”), second would be an object describing the context (in this case it could provide the article name, date, ID, URL). When a page wants to show an article, it calls this function for all registered plugins, in order they were registered. (There is one source file with hardcoded list of registered plugins.) Each plugin returns a HTML code, or empty value, and the page inserts the returned values.
What places exist? The ones we currently use. What values are provided in the context? The ones we currently use. Later, expand as necessary.
The other cases you mentioned sound more complicated...
Thanks a lot for the in-depth reply.
I must agree with you that there are a lot of dealbreakers for me there. But it’s interesting to see what goes into deploying & maintaining the website.
I do think that if you guys refactor it, it might be quite nice to put a “generic” version of it out there, including some instructions like these for people that want to run it. There’s a lack of well-executed open source community platforms at the moment.
This one may be messy and not the most efficient or prettiest in terms of the underlying code, but the user experience is one of the most polished I’ve ever stumbled upon.
...
The phone bit I find surprising though since in my experience I’ve had issues with LW on my laptop but on my android, it runs really smoothly (latest stable firefox on both). But I guess it depends on a lot of factors and “run smoothly” is rather subjective after a point.
Yeah, I strongly agree with this. There is a reason why we ended up building this one mostly from scratch, really none of the other options seemed very good.
Not directly an answer to this suggestion, but I’ve definitely been considering spending a month or so packaging up what we have so far, and selling hosting + support for it as a way of financing the LW team and getting us more financial independence. That would also have the side-effect of having everything more nicely packaged up for other people like you to run their own versions. But I don’t really know what the demand is, and I am worried it would make us a lot more hesitant to do small hacky one-off things that make sense to have on LessWrong, but don’t make sense to have for all of our other users (like the annual review system).
Would it be possible to split the current website into “core” (what other people might need) and “plugins” (currently one: the LW and EA specific functionality)? Each plugin could have its own tables, its own pages, and inject some HTML code into specified places in the “core” (or other) pages. The plugin support should not cover all hypothetically possible cases, only what is needed to make the current “plugin” run.
I agree that thinking about how changes might impact other users makes development (and release management) way more complicated. Would probably need separate “stable” (bugfixes only) and “experimental” branches.
But I find it interesting, how many people want to have online debates, and how much the existing solutions suck. I already gave up the idea of hosting my own web forum, because it seems like it would become a full-time job to moderate and fight spam—and the choices are whether the “full-time job” would consist of developing and maintaining my own solution; or learning how to use an existing one, updating it constantly because every two weeks there is a critical security update, and coding my own plugins to fix or add functionality anyway; I am not even sure which option is less work in long term. This is really not good.
It’s possible, but I really expect it to be a lot of work. We have a lot of shared UI and small interleaving pieces of functionality all across the site, and I expect this would cut off a lot of the design space we could explore, or basically just force everyone to run the whole forum anyways.
Like, we modify the code responsible for displaying post-items during the review to display the small “Review” button on the right. I don’t know how to factor that out so that you don’t even get that piece of code shipped, and these kinds of dependencies are all over the place. The comments UI depends on moderation guidelines in subtle ways, the recommendations for the frontpage depend on your view-history, but I would also like it to depend on your comment and vote-history, and this would become harder where everything is plugin-structured.
The visual design philosophy of the site is also very much centered around minimalism and trying to only present you with the information you really need in any given moment, which often leads to small design changes based on context that I find hard to factor out (contrast this with the usual PhPBB forums that tend to just throw small independent widgets everywhere in order to customize your experience, leading to what I experience as massive information overload, but having the benefit of being much more modular and you can easily turn off whether you display the last-commented time of a thread, or the total number of comments, or the total number of contributors, etc.).
This is exactly what I imagined. Each plugin would have a function “insert my code” with two parameters: first would be the name of the place (in this case e.g. “article widgets”), second would be an object describing the context (in this case it could provide the article name, date, ID, URL). When a page wants to show an article, it calls this function for all registered plugins, in order they were registered. (There is one source file with hardcoded list of registered plugins.) Each plugin returns a HTML code, or empty value, and the page inserts the returned values.
What places exist? The ones we currently use. What values are provided in the context? The ones we currently use. Later, expand as necessary.
The other cases you mentioned sound more complicated...