Of course, before any of that happens, there needs to be some agreement on what changes we think would be a good idea.
There already is: how many people follow/starred bugs on the bug tracker. If you want to help, just look at the most vexing bug and work your way down the list.
Newbie question: looking at the issue list, not seeing how to tell how many people have followed / starred a bug. Or am I looking at the wrong page?
Also, my impression is the places where there are big potential gains are not so much in little things where the correct fix is obvious, but bigger-picture things that are potentially controversial. I see on the issue tracker there are various things listed as "authorized" or "accepted," I assume that's a way for the powers that be to mark which proposed changes they want, but what's the difference between them?
https://code.google.com/p/support/issues/detail?id=1210 suggests sorting by stars should be possible.
Also, my impression is the places where there are big potential gains are not so much in little things where the correct fix is obvious, but bigger-picture things that are potentially controversial.
Personally, I wouldn't waste any time on a discussion of a potential big fix unless the instigating party had already shown the ability and willingness to hack on the codebase by, for example, fixing a number of 'little things'. (Since usually such people never contribute anything and so discussing their proposals is a waste of time and energy.)
I don't know what the accepted/authorized stuff means (if anything). Might as well start looking at the top ones and seeing what you can feasibly do.
Great to hear you're interested in contributing Chris. The LW codebase takes a bit to get your head around so I'd certainly suggest starting with smaller bugs or small features before diving into big new features. You should definitely get in touch with us (TrikeApps) and Luke to discuss what you want to work on to make sure it's the best use of your time and your approach considers all angles.
For reference, Accepted issues are generally bugs. The Accepted status indicates they have been reviewed and acknowledged as a bug. Approved is used to indicate tickets that are approved for work (generally by Lucas). These are good candidates to work on but you should definitely coordinate with us to make sure they aren't being worked on already.
I think it's great that you are offering your time for the betterment of LW. Kudos to you. (I think you already improve LW with your posts, by the way.)
You've brought up an "off-topic" subforum. What is the difference between this and the regular open thread? Would it mainly be that the link to it was constantly displayed at the top (up by Main and Discussion)?
A usage quibble: Did you mean "defuse" here?
it could diffuse debates over "what topics are appropriate for LessWrong."
Thanks!
I get the impression that the open thread tends to get used less for "off-topic" discussion than for brief and fragmentary thoughts. I admit this may not be the intent... but lack of clarity is part of the problem here. Adopting standard internet forums conventions, I suspect, would encourage better discussions. Open threads are standard for blogs, and LessWrong is a spin off of the blog Overcoming Bias, but it's clear that Discussion is currently squarely in the "forum," not "blog" category.
Yes. Thanks for catching that.
Please note that as of late last year the official development environment is now built with Vagrant. The primary repo contains a Vagrantfile and all the chef recipes (derived from our production recipes where possible) necessary to configure a base Ubuntu box for LW development.
The instructions for using this are at: Development-VM-Image.
Thanks for posting this. It provided me with just enough motivation to add "Download LW source" to my things-to-do-when-home-from-vacation TODO list.
Looking at how I follow through on such commitments in the past I think there's about an even chance I'll actually fix a bug or two!
Hi, I just successfully
Great! Why all that? I consider forking the LW reddit codebase for my own blog - mainly because I didn't find a commenting system that suited me. I may push back improvements into the main trunk. We will see. Just one question: What do I have to respect when using the codebase? Are there any licenses I have to take care of beside CPAL? http://opensource.org/licenses/CPAL-1.0
This is what I envision a good discussion forum would look like: https://medium.com/i-m-h-o/bc340a52f6a4 .
There's been some discussion of how to improve the structure of LessWrong at the site software level - for example adding subreddits or modifying how main and discussion work. One roadblock to this that's been mentioned is a shortage of programmer hours. I'd like to volunteer mine.
I recently finished a course on web development in which, among other things, I build a Reddit clone using Ruby on Rails and Backbone.js. It's been several months since I've written any Python, and I'm somewhat wary of the time required to get familiar with the LessWrong codebase, but I think think the time would be worth it for me: it could potentially improve LessWrong a lot and would let me tick off my "have contributed to an open source project" box.
Of course, before any of that happens, there needs to be some agreement on what changes we think would be a good idea. So... discuss.
EDIT: For context, it's been suggested that part of the benefit of subforums is it could defuse debates over "what topics are appropriate for LessWrong." We could even have an "off-topic" subforum, a common feature of online discussion forums - I think bringing the format of LessWrong more into line with what's standard on other websites could help newbies be less confused here.