At one point I was planning on making a contribution. It was difficult just getting the code setup and there was very little documentation on the big picture of how everything was supposed to work. It is also very frustrating to run in a development mode. For example, on Mac you have to run it from within a disk image, the VM didn’t work, and setting up new user accounts for testing purposes was a huge pain.
I started trying to understand the code after it was set up, and it is an extremely confusing mess of concepts with virtually no comments, and I am fluent in web development with Python. After 4-6 hours I was making progress on understanding what I needed to make the change I was working on, but I wasn’t there yet. I realized that making the first trivial contribution would probably take another 10-15 hours and stopped. The specific feature I was going to implement was an admin view link that would show the usernames of people who had upvoted / downvoted a comment.
The issues list on GitHub represents at least several hundred hours of work. I think 3 or 4 contributors could probably do a lot of damage in a couple months of free time, if it weren’t quite so unenjoyable. $10K is definitely a huge underestimate for paying an outsider. I do think that a lot of valuable low-hanging fruit, like stopping karma abuses and providing better admin tools, could be done for $10-20K though.
The specific feature I was going to implement was an admin view link that would show the usernames of people who had upvoted / downvoted a comment.
Thanks for trying to work on that one!
setting up new user accounts for testing purposes was a huge pain.
This seems like the sort of thing that we should be able to include with whatever makes the admin account that’s already there; I was watching someone running a test yesterday and while I showed them the way to award accounts karma, I didn’t know of a way to force the karma cache to invalidate, and so they had to wait ~15 minutes to be able to actually make a post with their new test account.
These sorts of usability improvements—a pull request that just adds comments for a section of code you spent a few hours understanding, an improvement to the setup script that makes the dev environment better, are sorely needed and greatly appreciated. In particular, don’t feel at all bad about changing the goal from “I’m going to close out issue X” to “I’m going to make it not as painful to have test accounts,” since those sorts of improvements will lead to probably more than one issue getting closed out.
Maybe it would be easier to make contributions that rely on the code as little as possible—scripts running on separate pages, that woud (1) verify that the person running them is a moderator, and (2) connect to the LW database (these two parts would be common for all such scripts, so have them as two functions in a shared library) -- and then have a separate simple user interface for doing whatever needs to be done.
For example, make a script called “expose_downvotes” that displays a text field where the moderator can copy the comment permalink, and after clicking “OK” a list of usernames who downvoted the specific comment is displayed (preferably with hyperlinks to their user profiles). For the user’s convenience, the comment id is automatically extracted from the permalink.
Then the moderator would simply open this script in a second browser tab, copy link location from the “Permalink” icon at the bottom of a comment, click “OK”, done.
Compared with the solutions integrated into LW web page, this solutions is only slightly more complicated for the moderator, but probably much more simple for the developer to write. Most likely, the moderator will have the page bookmarked, so it’s just “open bookmark in a new tab, switch to old tab, right-click on the comment icon, copy URL, switch to new tab, click on the text field, Ctrl+V, click OK”. Still hundred times more simple (and thousand times faster!) than calling tech support, even assuming their full cooperation.
Each such script could be on a separate page. And they could all be linked together by having another function in the shared library which adds a header containing hyperlinks to all such scripts.
At one point I was planning on making a contribution. It was difficult just getting the code setup and there was very little documentation on the big picture of how everything was supposed to work. It is also very frustrating to run in a development mode. For example, on Mac you have to run it from within a disk image, the VM didn’t work, and setting up new user accounts for testing purposes was a huge pain.
I started trying to understand the code after it was set up, and it is an extremely confusing mess of concepts with virtually no comments, and I am fluent in web development with Python. After 4-6 hours I was making progress on understanding what I needed to make the change I was working on, but I wasn’t there yet. I realized that making the first trivial contribution would probably take another 10-15 hours and stopped. The specific feature I was going to implement was an admin view link that would show the usernames of people who had upvoted / downvoted a comment.
The issues list on GitHub represents at least several hundred hours of work. I think 3 or 4 contributors could probably do a lot of damage in a couple months of free time, if it weren’t quite so unenjoyable. $10K is definitely a huge underestimate for paying an outsider. I do think that a lot of valuable low-hanging fruit, like stopping karma abuses and providing better admin tools, could be done for $10-20K though.
Thanks for trying to work on that one!
This seems like the sort of thing that we should be able to include with whatever makes the admin account that’s already there; I was watching someone running a test yesterday and while I showed them the way to award accounts karma, I didn’t know of a way to force the karma cache to invalidate, and so they had to wait ~15 minutes to be able to actually make a post with their new test account.
These sorts of usability improvements—a pull request that just adds comments for a section of code you spent a few hours understanding, an improvement to the setup script that makes the dev environment better, are sorely needed and greatly appreciated. In particular, don’t feel at all bad about changing the goal from “I’m going to close out issue X” to “I’m going to make it not as painful to have test accounts,” since those sorts of improvements will lead to probably more than one issue getting closed out.
Maybe it would be easier to make contributions that rely on the code as little as possible—scripts running on separate pages, that woud (1) verify that the person running them is a moderator, and (2) connect to the LW database (these two parts would be common for all such scripts, so have them as two functions in a shared library) -- and then have a separate simple user interface for doing whatever needs to be done.
For example, make a script called “expose_downvotes” that displays a text field where the moderator can copy the comment permalink, and after clicking “OK” a list of usernames who downvoted the specific comment is displayed (preferably with hyperlinks to their user profiles). For the user’s convenience, the comment id is automatically extracted from the permalink.
Then the moderator would simply open this script in a second browser tab, copy link location from the “Permalink” icon at the bottom of a comment, click “OK”, done.
Compared with the solutions integrated into LW web page, this solutions is only slightly more complicated for the moderator, but probably much more simple for the developer to write. Most likely, the moderator will have the page bookmarked, so it’s just “open bookmark in a new tab, switch to old tab, right-click on the comment icon, copy URL, switch to new tab, click on the text field, Ctrl+V, click OK”. Still hundred times more simple (and thousand times faster!) than calling tech support, even assuming their full cooperation.
Each such script could be on a separate page. And they could all be linked together by having another function in the shared library which adds a header containing hyperlinks to all such scripts.