In case you missed the first one, check out the se-quality-project tag. The quality project isn't one that we plan to ever finish, it's perennial and kicks in every 18 months or so after we've had ample opportunity to observe the efficacy of our previous efforts, changes in how people use our sites along with feedback regarding what they expected, and when new ideas seem promising enough to try.
It's time to talk about the areas that we're going to be focusing on. I'm going to give a high level overview of the types of things that we want to do, and touch briefly on things that we have in progress. I'll then turn it over to you.
It's then your turn to mention a feature-request that you think might be a great idea for us to evaluate for inclusion in this iteration, and we'll then take a look at all of it to see what we're going to be able to build.
We can't do all of it, but we're going to put the highest priority on small-ish things that could potentially make a big impact first, and then drill down into things that are going to take a bit of work, again with priority given to things that could help the largest number of users have a better experience on the site.
So, let's go over what we've got in mind:
Improving the new user experience
We want people to feel like they belong here. And in order to belong here you really need to be able to ask and answer questions competently, or contribute helpful things to documentation. It's that first part we're going to focus on first for the purposes of this project:
We plan to test a new, 'guided' version of the ask question page soon. This page would essentially break down all of the elements that make a great question, and give the user plenty of guidance as to why it's to their advantage to understand what's needed in each of them, and provide it.
We're launching an initiative with the University Of Melbourne in Australia. Some graduate studies have uncovered what (could) lead to much more precision in the detection of duplicate questions, as well as a huge improvement on what duplicates are suggested to the person asking. There will be a separate post about that this week. We need to help them validate a ton of data, they've come up with a system to make it easy for us to help. More to come on that soon.
Improving the experience of our existing users
We think the two things we've got planned in the new user experience category is going to have a pretty nice impact (most unhelpful questions don't need to be asked, if only we could let folks know we've already got their answers more effectively). But we want to do more.
We're going to explore some ideas for better filtering of the questions that you see indicated by information that you give us. If you really only enjoy solving medium to difficult problems, that's what we need to prioritize showing you. We're going to have some discussions on ways this can be accomplished when we come to it.
We're looking at some upgrades to the anti-spam and abuse mitigation systems. They've been good to us, but we need to keep them relevant. There are some awesome community-run projects that have been helping tremendously, and we're currently looking at ways that we might be able to integrate them more properly.
Improving the experience for our moderators
Because at the scale that we see on Stack Overflow, existing tools are really starting to show their age.
We want to end the need to manually suss out voting rings. We're working on making the scheduled tasks that identify these things much smarter, by teaching them to think like Shog9 and myself do as we analyze all of the data that we have access to. We'll find a lot more rings where action is needed, and stop showing moderators patterns that are actually pretty benign (but the tools they have really don't indicate that it's benign). Mods will get a sort of 'minority report' in cases where the system couldn't make an automatic decision explaining why it couldn't decide, show all of the information that the mod needs to make the call, and let the moderator decide. This is actively being worked on for feasibility, once we're sure the model scales we'll kick off a discussion with more detail.
We're going to do more to make certain that people understand what they're doing by flagging and help them choose the correct way to proceed (and in many cases that probably means not proceeding). We'll break out into a separate discussion when we get to this. Moderators are far too often called to look at things where they aren't actually needed, and this distracts them from looking at the stuff where they are actually needed. "Should I downvote, vote to close or flag? Should I do all of that?" - we need to make this much, much clearer. And we've got the inverse of that, folks downvoting spam when they really need to be flagging too :) It's not an easy problem.
None of these lists are exhaustive, there's more, but this is getting pretty long now. What's important is what you think we need to be prioritizing.
So what do you think we should include in this round? Try to link to the feature-request, but don't fret too much if you can't find it (just explain what it wanted, and we can rely on Shog9's RAM-like memory for the location).