I think they are slightly ashamed of censoring things, and it doesn’t pull their enthusiastic attention and desire to make it work well, and so it doesn’t get the dev and PM efforts that would go into, for example, an April Fools event?
No, not particularly. It is true that working on improving the user experience here is not especially motivating, but this cluster of bugs + bad UX is near the top of my internal to-do list of relatively important things to work on; there are just a lot of things to do (and that list seems to be growing rather than shrinking).
(Like the font isn’t even the right size! It is the only thing that matters on that page, and it is so tiny as to seem an afterthought… except that it is red so they clearly don’t intend it to be an afterthought. The programmer who set the color was thinking it should be big and obvious, and the programmer who set the font size had a different intent.)
The error message color and font size is one of the few remaining artifacts of the original framework that LessWrong 2.0 was built on (VulcanJS). Our story for correctly surfacing legible errors to users is quite bad, across the codebase.
And I think it is probably a bug to not let changes be published? (Though maybe they are afraid of some kind of adversarial dynamic and this is correct in order to make things hardened?
I made this change because I wanted to prevent people from making the contents of the rejected posts displayed on lesswrong.com/moderation misleading (with respect to the actual content that caused them to be rejected). The rejection feature was not designed with “post is modified to be un-rejected” in mind; this is not well-communicated in the UI. You should simply make a new post.
But it is at least it is a bug to accept edits (which consume time) and then refuse to let them be published (with no warning or explanation of this)?
Yes, this is basically an oversight.
I guess in a deeper sense, maybe their own policy is not actually be well articulated, plausibly because it was designed by a committee to satisfice the not-perfectly-compatible desires of various stakeholders, some of whom likely had incompatible mental models?
The policy about what users should (and should not) do is clearly described in the post that Seth linked above. There is no English-language description of all of its downstream technical consequences because we don’t have the (truly absurd) bandwidth that would be needed to satisfy that requirement in full generality, across all of the site rules (and other things that might motivate moderator action).
The policy was “designed” by me marinating in the ways in which the previous policy was inadequate over the course of many months of moderation work, writing up a new policy, running it by Habryka, adjusting the wording slightly, and then publishing that post. LessWrong sees regular engineering and moderation contributions from 6-7 people, and usually only 2-3 people on any given week. We do not have the people to form a committee.
No, not particularly. It is true that working on improving the user experience here is not especially motivating, but this cluster of bugs + bad UX is near the top of my internal to-do list of relatively important things to work on; there are just a lot of things to do (and that list seems to be growing rather than shrinking).
The error message color and font size is one of the few remaining artifacts of the original framework that LessWrong 2.0 was built on (VulcanJS). Our story for correctly surfacing legible errors to users is quite bad, across the codebase.
I made this change because I wanted to prevent people from making the contents of the rejected posts displayed on lesswrong.com/moderation misleading (with respect to the actual content that caused them to be rejected). The rejection feature was not designed with “post is modified to be un-rejected” in mind; this is not well-communicated in the UI. You should simply make a new post.
Yes, this is basically an oversight.
The policy about what users should (and should not) do is clearly described in the post that Seth linked above. There is no English-language description of all of its downstream technical consequences because we don’t have the (truly absurd) bandwidth that would be needed to satisfy that requirement in full generality, across all of the site rules (and other things that might motivate moderator action).
The policy was “designed” by me marinating in the ways in which the previous policy was inadequate over the course of many months of moderation work, writing up a new policy, running it by Habryka, adjusting the wording slightly, and then publishing that post. LessWrong sees regular engineering and moderation contributions from 6-7 people, and usually only 2-3 people on any given week. We do not have the people to form a committee.