95

I think we should have some mechanism that automatically flags certain meta posts (both child metas and here) for Stack Exchange staff attention when they get beyond a certain point. The thresholds would be something like (subject to tweaking):

  1. Post is or

  2. Post has a score of 50 or more (possibly adjusts based on site).

OR

  1. Post receives a bounty from 3 or more users (this will take weeks, I know, that's the point)

The idea is to prevent very highly voted posts from falling through the cracks. Here are some examples where this has happened (or, at the very least, a very long time passed between a staff response and an answer). These are just the some of the ones that eventually DID happen:

  1. Can we have a tool-tip with the full title for links to hot meta posts that don't fit into the side bar?
  2. Can we have [mcve] expand to http://stackoverflow.com/help/mcve in comments, please
  3. Badge progress reports
  4. Indicate the color (bronze/silver/gold) in tag badge notifications
  5. The flag pop up on heavily downvoted answers has grey text
  6. Custom jsFiddle for Stack Overflow
  7. On beta sites, the monospace formatting in a spoiler quote is evil.
  8. Warn new users when they ask a question after a previous question is closed, downvoted, or deleted

The bar for this should be very high. Possibly higher than the one I propose above. But it should exist, to handle the outlier cases that fall through the cracks, plus it will encourage more meta participation and voting (since it will add to the perception that voting really does matter), which can only be a good thing.

Response to @JonEricson comment

Could you expand on how you think this feature would help solve problems on the sites? It's not hard for us to slap when we don't like a feature request or don't have time to work on it or when it's blocked by some other feature or when the request is unclear, etc. But I don't know if that will fix the underlying problem. (As an aside, it's strange to call out meta posts that have been addressed. Is the problem that they weren't fixed fast enough? If so, I don't see how your proposal addresses that.)

In at least two of those links, someone tweeted at @balpha before they got noticed. In a third, I custom flagged one for dev attention and @AnnaLear fixed it within three days later. Some of these are huge fixes, some of them are small; the bottom line is that I don't know what you have noticed and what you haven't, which is why I didn't link to questions that haven't been addressed. Searching for unaddressed things might turn up lots of stuff you've thought about but never got a , or it might turn up stuff that fell through the cracks.

However, these questions took six months or more before any dev response, at all, but they were things that Stack Exchange clearly did support, because they happened. A system that nearly guarantees a dev response for the most popular posts will serve to:

  1. Prevent very easy things from falling through the cracks, like #1, #2, #5, and #7 above
  2. Facilitate communication "We love this idea, but it's very hard!" Like #6 above
  3. Increase morale and user participation on meta "hey my votes and bounties actually accomplish something!"

This is about fixing easy bugs faster / without missing any, and about increasing communication on the more difficult things.

Related, but not dupe (because this is a specific proposed solution, not a question):

Improve this question
10
  • 8
    Anything that will make this more organized has a "yes" from my side. +1!
    – M.A.R.
    Commented Aug 14, 2015 at 16:04
  • 8
    We know things tend to fall through the cracks and this is something that we've discussed internally lately. We are discussing how we can be more vocal about when we see requests, etc that have our attention.
    – Taryn
    Commented Aug 14, 2015 at 16:08
  • 1
    Could you expand on how you think this feature would help solve problems on the sites? It's not hard for us to slap status-declined when we don't like a feature request or don't have time to work on it or when it's blocked by some other feature or when the request is unclear, etc. But I don't know if that will fix the underlying problem. (As an aside, it's strange to call out meta posts that have been addressed. Is the problem that they weren't fixed fast enough? If so, I don't see how your proposal addresses that.)
    – Jon Ericson
    Commented Aug 14, 2015 at 16:26
  • 2
    @JonEricson Yeah, so like this one turned up and I imagine would be pretty easy, technically speaking. However, you may not want it, I don't know whether you've discussed it, etc.
    – durron597
    Commented Aug 14, 2015 at 16:46
  • 7
    see also: What privilege should 30k users get? "Guaranteed evaluation to status-* tag for open feature-requests at respective per site meta in one or two months..."
    – gnat
    Commented Aug 14, 2015 at 18:54
  • 6
    I think this is a good idea... and I'd like to point out that status-declined and status-completed aren't the only two options for status messages. There's status-deferred, -review, -planned and -bydesign. But, largely, FRs get no feedback at all. I certainly think that actually working on the site is more important than responding to questions but when people try to help and get nothing back, I feel that makes them less interested in helping.
    – Catija
    Commented Aug 14, 2015 at 20:08
  • 21
    BINGO! In most of the cases the problem is not that something isn't implemented for whatever reason, but simply that noone actually knows if the responsible powers have noticed a feature request or bug report at all.
    – Christian Rau
    Commented Aug 14, 2015 at 20:37
  • 4
    Yes, there is a problem in the way that we communicate that we've seen important meta posts. But no, this solution is a non-starter.
    – Jon Ericson
    Commented Aug 18, 2015 at 16:46
  • 3
    @JonEricson - thanks for tagging this question.
    – Deer Hunter
    Commented Aug 18, 2015 at 21:51
  • Also add to the list that it should not get flagged for attention if the question is a dupe..
    – Caleb Liu
    Commented Aug 1, 2022 at 23:39

9 Answers 9

Reset to default
23

I think there are two main things that need to be addressed for this feature:

  1. What problem are we trying to solve?
  2. What would a solution look like?

What problem are we trying to solve?

Our team is trying hard to get away from offering solutions, and instead spending more time on explaining what the problem is. A lot of the time we end up disagreeing on what to do because we are trying to solve separate problems and therefore will never be able to really agree on a solution.

So which problem are we trying to solve here? I see two:

  1. People feel like their posts are not being listened to and just want the CMs to show in some way that they are being heard
  2. There are a lot of good ideas that are being written up by the community but aren't being implemented by the CMs/Devs due to a lack of process

As anyone who's worked with other people knows, communication and getting things done tend to be in opposition. Time spent in meetings is time away from actually shipping stuff, and time shipping stuff takes away from the amount of time you have for meetings. In the same way, asking for more communication from us will take away from the time we have from implementation, and vice versa.

If we don't figure out which folks want to optimize for, folks will be upset with whatever solution comes out of it.

What would a solution look like?

I see three different sorts of solutions people are looking at:

  1. Acknowledgement that the feature-request has been seen
  2. More communication (comments, tags, answers) from CMs on feature-requests
  3. Transparency in implementation/the ability to see what's being worked on

Now all of these seem to support that the solution people want is more communication (even if fewer feature-requests get implemented). Here is a prime example:

we want only one thing at the moment - reduction in the number of bug and featreq questions on all metas without status tags. Having a CM tag on a question means there is feedback from the team. Of course, we'd like this feedback to be prompt and the backlog of untagged questions to eventually vanish to near zero.

I am very hesitant to see this as a solution for the whole community though. Meta users are a subset of all users (I believe 10% is the rule of thumb for meta participation by active users). If we reallocate time implementing features that benefit the 90% in order to communicate more with the 10%, will that improve the site on the whole?

I actually had this exact discussion with mods in chat on July 20th, and this is how I responded then:

I could probably spend this week and kill 2000 of those feature-requests. But guess what, that would also mean that the remaining 10,000 feature-requests without an answer will feel like they also merit an answer. So let's say I even knock off 90% of feature-requests with status-deferred or status-declined (as Jeff said, 90% of community feedback is crap), that leaves 10% of stuff we probably want to seriously look at but takes time.

We can't just put "status-planned" on them if we aren't actually planning them. And we can't put "status-deferred" without a reason we're deferring them. So they end up in a different limbo, but a limbo all the same.

In the meantime, we'll have used a whole bunch of manpower to actually go through thousands of old feature-requests we knew we probably wouldn't implement anyway, and that time probably could have been used to implement a feature-request that has merit and helps out everyone (like the new mod flagging for CM attention thing on user profiles).

At any rate, as stated before, this is something that I definitely think merits attention from us (on meta, not here), and it is something we are actively discussing. It also isn't an easy problem. So we hear your frustration, we want to fix it, but there isn't a quick fix for this right now so we ask for a bit of patience in the meantime.

What you can do in the meantime

There are two ways that we get things done based on feature-requests.

One Jon explained already is Community Requests -- we have already completed 64 of these in 2015. Those are pretty easy and get done very regularly (personally whenever I spot a good idea either on meta or in chat, I just toss it up on a card with details, and then someone usually fleshes it out for me and it gets implemented like that). These are low-friction changes in general.

The other are bigger projects. Think the new profile, the triage queue, design-independent graduation, etc. These are things that require devs, CMs, and sometimes more to figure out what it is we want to do, and what the best way is to do it. And we almost never get agreement without a lot of discussion on those. They are very brainpower/manpower-heavy, and people need to use a lot of their bandwidth on them to push them through.

How you guys can help is by helping to:

  1. Create a clear problem statement
  2. Aggregate similar ideas/ideas on similar topics

The best feature-requests will have a really clear problem statement rather than a solution. If we know what type of problem the feature is designed to solve, then it is much easier for us to use it (or not) when we are working on solving that problem in the future. And far easier to toss into a Community Request.

Let's take the triage/helper queue. I'd wager that the goal of that project (to provide more helpful/direct feedback to new users while helping improve the quality of questions on the front page) is something at least 1000 of those open feature-requests were related to. Since that isn't clear (but often the implementation is), we end up with a lot of feature-requests which are kind of in a limbo.

Often someone will take a bunch of different meta posts on a similar topic and toss them in to a super-post that clearly states what the issue is, suggests some previous meta posts that try to solve them, and explains what you like/don't like about those solutions. These are a great resource to kind of wrap up an issue.

When most of the information on a topic is in one place, especially when there's a clear problem statement, it becomes much easier to riff off or to use as a base when we are trying to solve that problem in the future.

I am not saying this means you will get an instant response, or that this will magically make our process better, but these are definitely things that I would appreciate when I was trying to tackle a problem, and one of the reasons that we put meta posts out there with the problem statement asking for feedback on how we're intending to solve them.

At the end of the day we're doing our best to both communicate and get things done. We appreciate you taking the time to make suggestions, and hope you'll keep working with us to make the site better.

Improve this answer
18
  • 11
    How will we know that project posts with cleat statement get status-tagged? Why should anyone bother writing them just to have them ignored? You don't have to reinvent the wheel, status feedback beats no status feedback hands down. Start from the top scoring ones and tag them. Then, as time allows, tag the next tier. Just don't give up on this activity. Please...
    – Deer Hunter
    Commented Aug 16, 2015 at 6:24
  • What would you think about a Meta question to aggregate cosmetic small feature requests / bug fixes into a single place?
    – durron597
    Commented Aug 16, 2015 at 20:26
  • 2
    @DeerHunter We don't ignore all of them. We have implemented 64 CRs in 2015 already (and have 4 more in the pipeline), and that's just the ones fixed through that process. Either you're upset because (a) we aren't implementing enough of them (which tagging stuff won't help accomplish), or (b) we aren't giving feedback on ideas you've posted. Why are you so insistent on getting tags on things?
    – jmac
    Commented Aug 17, 2015 at 2:28
  • @durron597 Cosmetic stuff to me sounds like it's going to be a bunch of personal preference on how something should work, rather than focused on a problem that should be solved to make the site better. If I'm wrong, and it's stuff like "these things are difficult to see/find and can confuse users", especially if they are all difficult to see/find for the same reason, that could be quite helpful.
    – jmac
    Commented Aug 17, 2015 at 2:29
  • @jmac I was specifically talking about issues like #1, #2, #5 and #7 in my original question.
    – durron597
    Commented Aug 17, 2015 at 2:30
  • 3
    People come to metas to be heard. If they are a voice in the desert they become apathetic. If apathy kicks in, they don't contribute to SE anymore. If they don't answer questions a site dies. If a site dies you lose your ad revenue.
    – Deer Hunter
    Commented Aug 17, 2015 at 2:34
  • @durron597 I wouldn't aggregate those unless they have a common thread that you can say as the core problem of all the issues. So if, for instance, there were 30 issues involving monospaced text, I would put those together and say, "Hey, monospaced text seems to be a bit wonky" and then we could fix those all in one fell swoop (hopefully). Hopping from formatting to tooltips to CSS is unlikely to speed anything up though.
    – jmac
    Commented Aug 17, 2015 at 2:40
  • 2
    @DeerHunter I thought people came here to give their ideas on improving the site, and discuss those that other people have. Y'know, coordinating community-wise. If your sole purpose of posting here is to get feedback from us (employees) on everything you (or anyone else) posts, then that's definitely a use case meta wasn't designed for. I think predicting the death of the site over this is a bit over-dramatic, but point heard.
    – jmac
    Commented Aug 17, 2015 at 2:43
  • 1
    @jmac It's about having one place for issues that are easy to fix, so the developers only have to look in one place and they cannot be overlooked. When an issue (answer) is fixed, it can be deleted (and 10ks can see all the old, undeleted answers, etc.). It's less about fixing them faster in the sense of "this is easier to keep track of", and more about fixing them faster in the sense of "they won't get overlooked".
    – durron597
    Commented Aug 17, 2015 at 2:44
  • 1
    @durron597 "easy to fix" is something that, after a year in this company, is totally impossible to predict. There are small small things that are virtually impossible to fix without totally refactoring the code, and mammoth things that can be done with a site setting. Tossing a bunch of unrelated issues in a bug report isn't going to help the folks fixing them, or the folks who send them over.
    – jmac
    Commented Aug 17, 2015 at 2:46
  • @jmac - 'give ideas'? To whom? Right, to someone who can implement them. That's the SE team, nobody else can do it.
    – Deer Hunter
    Commented Aug 17, 2015 at 2:50
  • @DeerHunter So again, either you're upset because (a) we aren't implementing enough of them (which tagging stuff won't help accomplish), or (b) we aren't giving feedback on ideas you've posted. There is no magic way to take a fixed amount of time and have us do more implementation and communication. It just isn't possible. I understand you're upset, but being upset doesn't change that fact nor will it help us make a change that will make you less upset.
    – jmac
    Commented Aug 17, 2015 at 3:14
  • It's b). If the team doesn't want to give triage, I can live with that. Stack Exchange cannot. Ultimately, you are impacting your own bottom line, shooting yourself in the foot. I shut up now, no need to listen to me anymore.
    – Deer Hunter
    Commented Aug 17, 2015 at 3:27
  • 8
    @jmac you (SE) are acknowledging less than one fifth of the feature requests in the past year with even a comment or status tag edit (much less an answer). A beta site that had less than a 20% answer rate would be closed for lack of community and expert involvement. The acknowledgment rate is currently about one per day. Unfortunately, I don't have any answers on how to improve that as I am not an expert in the workflow, workload, or development process used internally to Stack Exchange.
    – user213963
    Commented Aug 17, 2015 at 16:01
  • 3
    @MichaelT I get it. You wish that we had magical unicorn powers and could use those powers to magically fix everything that can't get done because we have limited time. Unfortunately, we have limited time. And that means that we cannot do everything that we would like to do. Apparently you think that feedback on 20% is too small. Given that an increase of that number will reduce our time spent on other things we do, what do you think is the best thing for the community here? For reference, rhetoric isn't likely to change the fact that time is limited and we are only human.
    – jmac
    Commented Aug 17, 2015 at 16:05
36

The problem here is that there is a mismatch between the role of the site to discuss (yes, the 'd' word) the site itself and the role of a public bug/feature tracker. Without any other visibility, meta is the only view that the non-SE employees have into the priorities, roadmap, and actual design of the bug/feature itself.

And thus, there is no way to really say "yes, that's on our radar, its blocked by this other issue (that is internal and we're not sharing information about)" in a good way. The site design itself is preventing this feedback.

To us, it looks like "here's a feature, doesn't get any response (but is actually on the internal list) and the SE types are ignoring us." This is a... lets call it "less than ideal" means of feedback to the community.

What would be useful would be a view into the bug tracker. Not the internals, not the hg commits (I assume you're using hg given some old Joel posts), not the internal discussion - but rather the public roadmap. Just the acknowledgement that "yes, we heard this and its on our list, its in the 'slated to do some day' and is blocked by bug private" or "yes, this has high priority and we're going to get it out in a month or so six to eight weeks."

Alternatively, one could make the site take on more roles of a bug tracker such that the moderators of the site (and this would be useful for persite metas too) to be able to tag with priorities and such so that we know you're not ignoring us.

Failing that, it can feel like there is a bit of apathy floating around over issues that we, the community, feel are important. That is less than ideal when trying to nurture a community.

Speaking from experience, my five of my top seven questions have zero or one answer only, no status- mod tag, an excess of +35 score and... well... why should I give another idea for how to improve the site if I don't get any feedback on my existing ones that sit there languishing except for the occasional dup target (so others can feel the same apathy as I do about it)?

No, the site isn't a project tracking site... but we don't have anything else and so expect this one to be that. Its not a good thing for a bug to be sitting in the bug tracking system without an assignee, priority, or roadmap target (even the 'wishful thinking' target). Its not good for the feature requests on this site to be in a similar state.

Improve this answer
11
  • You could even make a featured tag for "SE Feature Request Backlog" and "SE Bug Tracker" to denote when they are entered internally.
    – enderland
    Commented Aug 14, 2015 at 18:45
  • 3
    @enderland that first one has too many characters for a tag. They'd have to finally give in to this FR.
    – Catija
    Commented Aug 14, 2015 at 20:11
  • 2
    @enderland We have an internal dashboard that pulls all [bug] and/or [feature-request] posts from all metas. There is no separate internal bug tracker that things are "entered" into.
    – Adam Lear StaffMod
    Commented Aug 14, 2015 at 21:28
  • 3
    @AnnaLear That's great! Though it makes me wonder, how does a question like this one get missed for 10 months, then? Does your internal dashboard import the score of the post? Maybe that's the solution we need
    – durron597
    Commented Aug 14, 2015 at 21:34
  • 17
    @AnnaLear it may be useful to writeup a blog post that is something like, "what actually happens when you post a [bug] and/or [feature-request]" - visibility into what happens for those of us peons who are not Stack Exchange employees... :)
    – enderland
    Commented Aug 14, 2015 at 21:34
  • Just so its out there, they use git
    – Braiam
    Commented Aug 14, 2015 at 21:50
  • @Braiam I was basing my guess on Hg Init and an old Joel post.
    – user213963
    Commented Aug 14, 2015 at 21:52
  • 3
    @durron597 I think that was a great call to not do anything about it. A title is cut-off, one-click and you have the full story. Having that title chopped off doesn't bring the plane down...Balpha is a nice guy ...
    – rene
    Commented Aug 14, 2015 at 22:05
  • 2
    I don't think this is a problem relevant to the question. It seems to simply be asking for a developer or moderator response (i.e. acknowledgement), not necessarily a detailed explanation of the progress and minutiae of implementation.
    – TylerH
    Commented Aug 16, 2015 at 22:50
  • 1
    @TylerH its a mismatch between the bug/project tracker role, the role of meta to discuss stack exchange, and the Q&A format of all of the stack exchange sites. The combination of all of these makes meta a poor way for the community to offer and receive feedback on the features and bugs. If you look at the trello development board you will see how that company (cousin to SE) is using it. The Q&A format does a very poor job of organizing and communicating SE's version of the troll development board. Excessive dogfooding tastes bad.
    – user213963
    Commented Aug 16, 2015 at 23:03
  • 3
    "We have an internal dashboard that pulls all [bug] and/or [feature-request] posts from all metas. There is no separate internal bug tracker that things are "entered" Wow, seriously? This from they guys that made Fogbugz where Joel emphasized that every bug needs to be assigned to a single person at all times? If you have no other internal tracking system how do you know which person is assigned to which bug?
    – gman
    Commented Sep 3, 2016 at 18:28
21

Ok, this was going to be a comment, but it got too big for a few hundred bytes.

The AMAgeddon at Reddit was in part caused by a lack of communication from the corporate overlords to the moderators of the various communities. When some very public changes happened, that was the straw that broke the back. Fortunately here, there are no beloved moderators that one can fire that would cause such outrage (when was the last time people saw an SE diamond answer a question on an established site meta? ... other than Stack Overflow).

However, the thing to remember is community moderation here. There aren't just the diamonds, there are the 3ks, 10ks, 20ks out there that are trying to help moderate the site.

On more than a few sites, the community doesn't have sufficient tools at their disposal to be able to properly and effectively moderate the overwhelming wave of crap (and it's August now... just wait until September on those sites were coursework can be asked) that is constantly pouring forth from the floodgates of the internet.

So we ask for better tools. Ways of using the tools more efficiently. These are the feature requests that show up on MSE and the per-site metas. The core group on a site is often concerned about making sure that the quality questions on it thrive. That is something that is hard to do when they don't have sufficient tools to stem the periodic flood of poor questions (hello September in 17 days) or lack the eyeballs on less established sites - trying to attract people to answer the questions there (or catch questions from other sites that really should be migrated).

When we don't get a response, the feeling is that we get is that Stack Exchange doesn't care about stemming the flow of crap or encouraging good questions and answers to thrive, but rather the views. That's understandable - views are the business model.

We feel like we are being forgotten (even though it is said that we aren't - please check the comments). That the priorities that the community have don't align with those that Stack Exchange has. The conflict and disillusionment occurs when there is a disconnect between these two sets of expectations. It is especially problematic when this disillusionment occurs in the more active core of the site's community and the repercussions that has with the community moderation, diamond mod workload, and perception of the site as a whole.

  • There are 15333 open feature requests out there.
  • There are 11768 open feature requests without a 'status-' tag on them.
  • There are 10041 open feature requests without a 'status-' tag on them where a first page by reputation moderator hasn't posted an answer (and realize that you're getting animuson in that count) query
  • There are only 3622 open feature requests that lack a 'status-' tag on them where a first page moderator has posted an answer or commented on a post in the question or answer. query

Lets narrow that time range down a bit.

Since August 1st, 2014...

  • There are only 233 open feature requests that lack a 'status-' tag on them where a first page moderator has posted an answer or commented on a post in the question or answer. query
  • In the same time frame, there have been 1298 feature requests that are still open that lack a 'status-' tag query
  • There are 207 feature requests asked in this timeframe that have a status tag. query

While I realize that the users greatly outnumber the SE employees, this is an average of just under five feature requests a day to be read by and commented on, answered, or status- tagged. As one of the non-diamond, active, volunteer, community moderators on Programmers.SE (and I will point out that SE employees vastly outnumber the non-diamond, active, volunteer, community moderators on Programmers.SE), we are able to find the time to comment, answer, vote, and moderate an order of magnitude more than that each day (and it's not September yet).

You know that giving feedback (positive or negative) is the most useful thing for retaining new users and that doing nothing is the best way to lose them. The same holds true for retaining a community.

Improve this answer
19
  • 2
    What is that "AMAgedon" you speak about?
    – Christian Rau
    Commented Aug 14, 2015 at 21:12
  • 6
    @ChristianRau they had a bit of a crisis where a combination of corporate actions (firing two well liked and public employees that were key to the community - corporate linkage) and a long simmering disappointment at the lack of tools the community moderators had resulted in the community moderators shutting down a significant fraction of the site.
    – user213963
    Commented Aug 14, 2015 at 21:14
  • 1
    Re: your second paragraph... Abrupt change in moderation staff?
    – user259867
    Commented Aug 14, 2015 at 21:53
  • 4
    @NormalHuman I wouldn't exactly call Hopeless a beloved moderator.
    – user213963
    Commented Aug 14, 2015 at 21:55
  • 1
    Nobody is universally beloved. He had enough support for the discussion there to be what it was. Anyway, to directly answer your point about an SE diamond answering on an established meta... about three hours ago.
    – user259867
    Commented Aug 14, 2015 at 22:04
  • 2
    @NormalHuman that post was five months ago. My point was about the sparseness of feedback that persite metas receive. My own example is the "it's not in any way forgotten - It'll take a day or two to refine some queries, at which point I'm going to start watching it." from a year and a half ago which is disappointing.
    – user213963
    Commented Aug 14, 2015 at 22:06
  • 1
    That question wouldn't have made either criteria suggested by this question. How would you propose we prioritize?
    – Jon Ericson
    Commented Aug 15, 2015 at 5:52
  • 3
    Hmmm... Looking again, this is the opposite problem from the one the proposed by the question: Tim answered right away and hasn't come back with an update.
    – Jon Ericson
    Commented Aug 15, 2015 at 6:05
  • 6
    @JonEricson it is the same underlying problem of a lack of feedback and communication. There is the perception that a post to meta as a feature request that people like is something that gets forgotten. It is a consistent "we (the core group) lack the tools to maintain the quality of the site that we expect" it is a "we don't know what we are expected to do given the lack of clear communication about the expectations, goals and direction that SE wants to go in." Be it a never commented on feature request or a "we'll look into that" a year and a half past.
    – user213963
    Commented Aug 15, 2015 at 12:48
  • 1
    @MichaelT "They had a bit of crisis" could easily have been read as SE instead of Reddit, since you didn't clarify. Chances are that, not having heard of AMAgeddon, Christian has never used Reddit, or at least isn't a regular user thereof. :-) (Of course, that's easy for me to say: to this day, I still don't get the point of Reddit, so I never visit it except to read the occasional AMA.)
    – C. K. Young
    Commented Aug 16, 2015 at 2:39
  • 2
    @ChrisJester-Young Exactly, to this day I've never even understood what Reddit actually is, apart from hearing it pop up in occasional internet speak.
    – Christian Rau
    Commented Aug 16, 2015 at 11:53
  • 2
    ... I will also point out that /r/java is where I learned about the JVMLS videos. Road to Valhalla, Java goes AOT, and The Secret History and Tragic Fate of sun.misc.Unsafe which incidentally has Oracle people looking at Stack Overflow search and questions and thinking its 'fairly entertaining' (6:38).
    – user213963
    Commented Aug 16, 2015 at 13:21
  • 1
    ... and the data.se link was against the main site too, and presite metas don't have bounties. The bounty suggestion was likely referring to MSE as its the only 'meta' that has bounties (and reputation changes) active on it.
    – user213963
    Commented Aug 16, 2015 at 13:30
  • 4
    ... as to how to prioritize, I've used task trackers that have due dates, project trackers that have integration to other tracking systems, queries against databases that generate reports to managers that something appears to have fallen off the radar and requires action. There are many options which depend on the internal tools and workflows of the organization that depends on the alignment of the issues raised with the business priorities. Fortunately, as a coder I can ask my manager about those business priorities. As a content generator and community moderator, that is difficult at best.
    – user213963
    Commented Aug 16, 2015 at 13:35
  • 1
    "Fortunately here, there are no beloved moderators that one can fire that would cause such outrage " Wow, this answer did not age well! :P
    – Mason Wheeler
    Commented Nov 20, 2019 at 16:36
14

Neither of your suggestions are particularly hard to implement. The search is:

is:question [bug] or [feature-request] score:50 -[status-completed] -[status-declined] -[status-bydesign]

And you can find questions that have been offered bounties by three or more people using SEDE. The problem isn't finding these requests and bugs, it's getting them to the attention of the people who can fix, implement, or respond to them. Generally, that requires a developer at least. Some fixes also require a designer or a Site Reliability Engineer (SRE) or even a Community Manager (CM). It turns out that a "5 minute fix" takes a lot longer if you have to communicate it to someone else. That's one of the lessons of The Mythical Man Month. Once a team grows beyond about 5 people, communication becomes the bottleneck. (That said, we are hiring.)

We tackle smaller feature requests (those that take less than a developer day or so) with a weekly ritual called Community Requests (CR). It's no longer a meeting because the Community team has gotten too large, but Shog referenced the process in passing last fall. During the week, CMs write up features we'd like implemented on a Trello card. Often these ideas are at least inspired by features written up on meta. Typically we dig deeper into feature requests to understand not just what is being asked, but why the feature is needed.

Please take a moment to read what Kathy Sierra says about listening to users:

This is tricky, of course, because it's not always obvious which user complaints/suggestions are based on real problems with your product, vs. naive feature requests that would do more harm than good. (Don't forget the Happy User Curve)

And this is NOT about giving them simply what we know is good for them but that they really don't want, because they probably won't stick around. This is about giving them what they really DO want... but simply don't realize it because they had no way to imagine it.

So even an easy bug to squash or a straightforward feature can take considerable time to analyze if you make the mistake of analyzing them. It's especially true 7+ years into a project since most of the low hanging fruit has been consumed. Therefore, once a CR is fleshed out by one CM, it's reviewed by the rest of the team. Sometimes our team has good reasons for rejecting the idea. If so, CRs go back to the drawing board or are removed altogether. Ideally, we also provide feedback to the meta question that prompted the request.

When we are satisfied with a feature, our representative presents it to the developers during their meeting early in the week. At that point, the developers make a decision and let us know that either:

  1. The feature has been assigned to a developer who is familiar with the relevant code/situation.
  2. There's some reason for not implementing the feature that we didn't notice.

Even when the developers accept a feature, they don't always implement them immediately because they discover some other problem that wasn't clear until you dig into the code. (For instance, one of my features is blocked by, of all things, the Denver data center.) More often, the feature gets implemented a few hours later as if by magic.

So that's a heaping helping of process right there. (Notice how many acronyms, the detritus of process, I used. I didn't even use all of them because I can't remember off the top of my head what the P stands for in PM. I think it's Product Manager, but I think of them as "our representatives".) Why don't we cut all that out and just let developers fix things? Well, developers do fix things all the time. You've listed 8 features that were implemented and none of them went through the process I just described. It's just a matter of getting the request in front of the right person when they have the time to do something about it.

Summary

We have a weekly process in which the CMs try to pitch three or so softballs feature requests to the developers. Individual developers also read meta and fix things that are trivial. But we really need to think beyond just incremental improvements:

Big Frickin' Wall

It's probably a good idea for us to respond to more feature requests (especially to describe the reasons for rejecting them), but I don't think this proposal is the right way to force us to do that.

Recapitulation

I see that I'm not getting across the crux of the problem. You see that image I stole from Kathy Sierra? This is a lot closer to our current situation:

More like HERE.

This is a mature project. There are still thousands of things that could be fixed or improved, but we are well into edge cases at this point. On my previous job, our software went into maintenance mode, which meant no new features. We certainly aren't ready to do that with Stack Exchange, but I do think that would be a rational decision. The only features that desperately need fixing/implementing right now are moderator tools that are only seen by a tiny fraction of users. Odds are, one or more of us has seen the popular feature requests on meta and have no intention of pushing them along.

Let me take a crack at the top five results of the proposed search:

My point is that while these highly-upvoted feature requests represent real problems on the sites,* they are either difficult problems to solve or deep edge cases. We have a tradition of interacting with users on meta and it's important that we continue that tradition. But I think you deserve more thoughtful and honest feedback than a quick on a few highly upvoted questions. I just can't see how a rigid requirement to respond to a particular set of meta posts will help you feel we care. If anything, it seems likely to damage the relationship we have with the meta community.

* I have my own pet peeve.

Improve this answer
31
  • 14
    Honestly, this sounds like "we're not going to give any visibility into which features are queued. We are only going to give feedback when either rejected or when they are completed." Is that your intent here?
    – enderland
    Commented Aug 14, 2015 at 19:02
  • 7
    That's frustrating to me as a user because frankly SE has a hugely active userbase that runs the Q/A part of their business model (ignoring careers, which is the primary revenue part of SE). Not having a way for me to get feedback about which idea SE is planning on addressing discourages me from contributing ideas, since as is pretty known by most people, there are even in your example almost 250 very popular requests that have no official input from SE on (and that's just meta.SE, ignoring all site specific metas).
    – enderland
    Commented Aug 14, 2015 at 19:05
  • 7
    @JonEricson it's not a problem except it indicates arbitrariness in how features get implemented. Which is annoying as a user, because now I see some people's features otherwise arbitrarily get implemented because of a twitter post and those that are going through the "official" process (as intended) get ignored inspite of considerable community support... imagine that you tell a group, "no one gets candy without talking to Jon" but then random people get candy without talking to Jon - that's not good for the community, generally.
    – enderland
    Commented Aug 14, 2015 at 19:07
  • 8
    I guess what I'm saying is, all this complicated rigamarole you outline above prevents stuff that could be fixed very quickly from not being so. And I don't want to establish a precedent of rewarding people for blasting developer twitter accounts with feature requests, because that will just encourage more of the same until the devs have to anonymize themselves. I don't know if my solution is best. Having a dedicated bug tracker with a public viewport would help a lot. Really more than anything else I just want any sort of standardized mechanism where popularity begets responses.
    – durron597
    Commented Aug 14, 2015 at 19:10
  • 8
    @JonEricson that doesn't let us know if the feature is even on the radar beyond "someone in SE is one of the couple hundred views". Is there a trello card for the feature? Is it in the "someday this will be nice to have" or "this is a part of a set of features we want to roll out in the next 3-6 months"? Do we need to try to get a dozen people from chat to post a non-helpful answer to get the +88/-3 (1 answer currently) question an eyeball glance at Stack Exchange? Or is it going to languish there until some day a dev does a "status-completed" a few months after an alternate approach is done?
    – user213963
    Commented Aug 14, 2015 at 19:13
  • 17
    Jon, can't tell about others but even status-noticed would do for me (status-trelloed would be even better). You see, I am not even looking into evaluation. Knowing that it's somewhere in pipeline would save me from trouble of poking about it over and over and over again
    – gnat
    Commented Aug 14, 2015 at 19:20
  • 5
    ... and @gnat has done a lot of poking.
    – user213963
    Commented Aug 14, 2015 at 19:24
  • 8
    If every single request of mine and of every single other person posting in this comment thread here would suddenly be status-declined I would be so much happier. "We care about you, we've thought about what you've had to say, we just disagree" is so much better than "your request has 90 upvotes but we're ignoring it because we just don't look at popular requests sometimes" (it goes without saying I'd be even happier with status-planned or status-review or status-deferred, I'm just making a point)
    – durron597
    Commented Aug 14, 2015 at 19:26
  • 12
    @JonEricson We're not even asking for that. Just a acknowledgement that "yes, this is on our roadmap - a CM has created a trello ticket for it, its in the wishfull-thinking category though and no dev has touched it." That's it. Or "Nope, not going to do this at all because we're headed in a different direction." However, if you are going to solicit feature requests on meta, there needs to be communication back that yes it will be done, we would like to but have not placed it anywhere near a low priority yet, or not it won't. Otherwise there is no point to it at all which is disappointing.
    – user213963
    Commented Aug 14, 2015 at 19:41
  • 8
    @JonEricson if you don't want to gather input from users, just blacklist feature-request and be done with it. Again, I'm fine with that, it's your website. But don't at the same time actively solicit them and give people the appearance that by having community support for an idea it's important to SE. The disconnect is the problem. The outcome is not, but clear expectations from SE about what the purpose of feature-request is would be very helpful...
    – enderland
    Commented Aug 14, 2015 at 20:21
  • 11
    Where's the problem of just slamming a status-review or status-planned tag on a thing. Even if it gets implemented in 5 years or never, I at least know you have seen it.
    – Christian Rau
    Commented Aug 14, 2015 at 20:49
  • 8
    @MichaelT wrt poking, I think it would be fair to note here that I don't poke anymore. My bounties for last year (probably two) are exclusively to educate meta community. I totally dropped the idea that SE team can be responsive; when some of my requests get status-* tag, I perceive this just as randomly generated event, "some stranger passing by said hello to me for their own reasons"
    – gnat
    Commented Aug 14, 2015 at 21:32
  • 13
    Response to your response: 1. Should be tagged status-deferred. 2. Should be tagged status-review, because we know it is from my other question about this. 3. status-review or status-deferred both an improvement over now. 4. Fine, status-declined it. 5. Thank you for status-declined. I mean, why not put those responses in those questions? Why put them HERE where they won't be seen?
    – durron597
    Commented Aug 15, 2015 at 0:06
  • 15
    To clarify: Those tags and the one to two sentences you wrote here are all that we're asking for.
    – durron597
    Commented Aug 15, 2015 at 0:09
  • 9
    Exactly that. Don't excuse why you can't or won't implement it with a page-size meta answer each, just assure us you've actually read those questions, which you just did.
    – Christian Rau
    Commented Aug 15, 2015 at 1:02
13
+100

Don't let the perfect be the enemy of the good.

I think that sentence summarizes the communication disconnect between the community and Stack Exchange on this issue.

Here are some excerpts:

This came up a couple of weeks ago. (I think in the podcast room?) We might end up doing something like that, which, I guess, will make people happy. But it's going to take a long time to tag every question that has at least some merit. - Jon Ericson♦ 19 hours ago

Might be a good idea if it's a big enough problem. I'm not going to spend the rest of the afternoon seeing how often this situation occurs on Stack Overflow, however. - Jon Ericson♦

@durron597 I'm clearly not understanding your question. It seems the problem is that minor features and bugs are addressed late? There are 79 questions a day on all metas. Often the discussions and support are more pressing than feature requests and bugs. It's a bit overwhelming sometimes. - Jon Ericson♦

@MichaelT: My answer is attempting to give you an idea of the scope of the problem. We could potentially open the Trello board to the public, I suppose. (Don't hold me to that; we'd have to agree to it as a team.) But I don't think that would get to the root of the problem because the real problem is that it's nontrivial to connect a feature request to the person who can address it. The solution is a much smaller codebase, a much smaller dev team, a much smaller user base, and a much smaller database of feature requests. We can do better, but we can't make our process completely transparent. Jon Ericson♦ 21 hours ago

But I think you deserve more thoughtful and honest feedback than a quick on a few highly upvoted questions. I just can't see how a rigid requirement to respond to a particular set of meta posts will help you feel we care. If anything, it seems likely to damage the relationship we have with the meta community.

After reading all of these things, it seems to me that:

  1. Stack Exchange wants to give full, complete, thorough responses to everything we post on Meta. (great!)
  2. Unfortunately, Stack Exchange feels that there is simply too much content to give complete, thorough analysis to every single idea. Some of these analyses are involved and those particular ideas don't seem to have much good return on investment.
  3. Eventually, as big checkpoints get reached, lower priority ideas will eventually be responded to.

To which I say again:

Don't let the perfect be the enemy of the good.

Promoting my comment to part of an answer about the top five questions that meet my criteria:

  1. Should be tagged .
  2. Should be tagged , because we know it is from my other question about this.
  3. or both an improvement over now.
  4. Fine, it.
  5. Thank you for .

I mean, why not put those responses in those questions? Why put them HERE where they won't be seen?

Not every question has to have an involved, long writeup.

Saying "we've looked at this, spent half an hour thinking about it, decided the return on investment isn't very high " would go a long way towards fostering good will towards the community and make us think that you are listening to the issues we care about (because we've upvoted and/or bountied them). It also would ensure that easy bug fixes would never accidentally get unnoticed despite having a score of almost 200.

For good measure:

Don't let the perfect be the enemy of the good.

Improve this answer
23
  • 8
    Don't let the perfect be the enemy of the good. <- this is the motivation behind my suggestion here. It's not perfect but does a lot about facilitating interaction between SE and its users.
    – enderland
    Commented Aug 15, 2015 at 17:21
  • 5
    @jmac True. However "And more communication invites more communication." is the slippery slope fallacy; I am asking for communication a cross section (feature requests and bugs only) of a cross section (above a certain popularity threshold) of posts. This does not commit Stack Exchange to replying to all posts (which I agree is too time consuming!), nor does it establish any sort of precedent for future communication increases.
    – durron597
    Commented Aug 15, 2015 at 17:55
  • 4
    Sorry if I wasn't clear. Us CMs are human. Our time is limited. You want us to communicate more -- that will take more time communicating then we currently do. No matter where you want us to carry out that communication, it will take more time. There is no slippery slope there. The second we guarantee a response (even with criteria) is the second people will push to be guaranteed a response (requiring more time on communication). Again, not opposed necessarily, but it is definitely a trade off.
    – jmac
    Commented Aug 15, 2015 at 17:59
  • 3
    @durron597 Is your interest in giving a subset of requests a larger portion of our attention (and more of our time to communicate the status)? Or is it to just clear the queue and process these? They are very different requests. 1/day (which is silly due to context switching costs) sounds like process. Half of the comments are about more communication. These have very different goals and solving one will not solve the other naturally.
    – jmac
    Commented Aug 15, 2015 at 18:16
  • 1
    @jmac It will prevent the small bug fixes from getting missed, at the very least. (Also, two sentences is a minimum, I'm not denying the possibility of better responses if you have time :-P)
    – durron597
    Commented Aug 15, 2015 at 18:23
  • 6
    @jmac - a transparent triage system is what we are asking. A surgeon going around a field hospital takes no more than several seconds to slap tags on the wounded: those who'd live, those who'd die anyway, and those who have to be taken to the table. If he procrastinates, bad things happen. Right now, the whole CM team is hit by the SO close vote syndrome - the queue looks untolerably long. Resisting public triage does nothing to alleviate the problem.
    – Deer Hunter
    Commented Aug 15, 2015 at 19:31
  • 1
    @DeerHunter there are 3 things the community is asking for here which are all different. (1) people want us to read every single bug/feature-request and leave a mark that we've seen it (2) people want us to communicate/give feedback on bug reports (3) people want to know which we are working on. That's because people have different goals. Some feel we are bad at communicating what the status is. Others feel we are too slow at implementation. These are two different problems with two different solutions. Do you agree?
    – jmac
    Commented Aug 15, 2015 at 22:58
  • 3
    @jmac - these three things (and two problems) have one common denominator - feedback. Yes, the team are 6 to 8 months away from implementation, and yes, communication is lacking. It is understandable that with persistent backlog of issues nobody wants to present her/himself in an unfavorable way, and without a structured way of tracking tickets requests get lost and never found again. This is self-reinforcing and ultimately spirals out of control.
    – Deer Hunter
    Commented Aug 15, 2015 at 23:34
  • 1
    @jmac - ... yet we want only one thing at the moment - reduction in the number of bug and featreq questions on all metas without status tags. Having a CM tag on a question means there is feedback from the team. Of course, we'd like this feedback to be prompt and the backlog of untagged questions to eventually vanish to near zero. To make your job easier we'll be fine if you stipulate a threshold (a question's minimum score) after crossing which CM triage starts for real (assuming that the community at large does the preliminary triage by voting up and down).
    – Deer Hunter
    Commented Aug 15, 2015 at 23:40
  • 1
    @jmac - for everybody involved to be free from subjectiveness (yes, you guessed right - I'm about to eulogize qualitative metrics), it would be nice to have each meta display prominently numbers of untagged bug/featreq questions above the threshold and median time to initial status tagging action.
    – Deer Hunter
    Commented Aug 15, 2015 at 23:45
  • 1
    @DeerHunter made an answer to respond: meta.stackexchange.com/a/263726/209637
    – jmac
    Commented Aug 16, 2015 at 3:50
  • 1
    Just so you know, I don't think you understood any of the things you quoted. If nothing else, it's a stretch (and not to say, wrong) to extrapolate what "Stack Exchange" wants from what I wrote. But more importantly, you cut out all the context which is often important. If you want the blunt truth: I think those status tags do more harm than good. I'd burninate them today, if I had absolute power.
    – Jon Ericson
    Commented Aug 17, 2015 at 23:52
  • 4
    I understand that Jon. My point is, you better figure something, maybe not exactly the same but something similar. I understand that there are cases when you'd want to continue interaction. But while you can't (due to resources constraints), leaving them just hang in there without any notice doesn't feel right, as indicated by this very thread. Result of this approach is folks feel abandoned and this may led to frustration. You better figure a quick way to help them see that their requests are on the radar, without over-committing ("triage" as someone already mentioned in other comments)
    – gnat
    Commented Aug 18, 2015 at 5:40
  • 1
    @gnat and durron: The part I'm repeatedly failing to communicate it that replacing your frustration with a Herculean task fails to make the site better, which is what the goal of feature requests and bug reports is. We can talk about how to help you feel less frustrated, but trying to fix our internal processes without bothering to understand them is not constructive.
    – Jon Ericson
    Commented Aug 18, 2015 at 16:46
  • 3
    ...I would want people to stop repeatedly asking whether SE team have seen their requests or not and instead, could somehow see that it's indeed the case, without making repeated meta threads
    – gnat
    Commented Aug 18, 2015 at 17:19
13

I know this seems frustrating at times - believe me, I've been plenty frustrated by it myself.

But I wanna just assure you that patience is rewarded. Though the mills of SE devs grind slowly, they grind exceedingly fine...

Improve this answer
9

We already have one. If anything has been demonstrated by the context of this discussion the guaranteed way you can SE to move is to post on twitter. This seems counter-intuitive, since "why should I post in another platform to get attention to my issues?", but it seems that's what the pipeline is shaping as. This hasn't been the only instance of this response by SE, and I suspect it wouldn't be the last.

Improve this answer
7

One potential way to do this would be to create a feed/dashboard which displays the top 5 upvoted (3 on smaller metas) and posts for each meta that do not have a Stack Exchange specific tags (completed, rejected, etc). This can be either internal to SE or both internal/external.

Make posts require a threshold of positive vote count (for example 100 on meta.SO/SE and 15 on smaller site metas - please don't bike-shed over these numbers without viewing/tweaking queries below, they are trivial to change too) before they appear on the dashboards.

Set a very long time threshold before they get a "check me!" alert, 60 days. This period starts from when the post is added to the dashboard. After this point, it means:

  • The meta post is top 5 (or 3) community voted items in un-addressed bugs/feature requests on that meta
    • This may encourage community to participate more in older suggestions, too, if this list is viewable external to SE
  • It has been untouched by SE officially for 2 months
  • It is above the threshold for "look at me!" which should indicate a site community feels strongly about something

The alert is triggered internal to Stack Exchange and is basically "check this meta post!"

This limits the information needing to be reviewed (except initially, I suppose.. ? though only a maximum of 5 (or 3) posts will be on the list) significantly, but still provides an easy way for Stack Exchange to view what their users view as most important.

It minimizes the work required by SE employees prompting with only the most important posts, determined by the community and does not compel any action (could be status-rejected, which is fine). It provides the community clear criteria for how to get SE to review a suggestion/bug - not implement/fix, but at least review. Keep in mind the 2 month timeframe (plus likely a few days/weeks to actual be reviewed) for each meta post will limit the number of posts receiving alerts... meta and meta.SO will generate the most, while smaller sites may never generate alerts.

As far as volume of dashboard-eligible posts, there is one post on Workplace meeting this criteria, five on Programmers. There are only 100 on meta.se and 46 on meta.SO total right now.

Improve this answer
5

There is an existing method to bring meta posts to the attention of the SE team, any moderator can ping them in chat and ask them to take a look. This is quite an important mechanism for features or bugs that only affect a single site, and part of the job of a moderator is to bring important meta posts for your site to the attention of the SE team.

In my experience this works pretty well, I can usually get at least a quick comment on what SE is thinking, often an explanation on why this feature isn't implemented right now or at all. And of course sometimes SE just implements it.

This process can be rather slow, I try to be careful about which posts I bring to the attention of the community team, and how often.

I agree that there is a problem with distinguishing whether a feature request is just too complicated to implement, a bad idea or was simply not seen by anyone from SE that can evaluate it. But I also don't think this is easy to solve.

Improve this answer
1
  • 10
    Perhaps the problem is that there's no organized communication method for users to moderators about issues to get escalated to devs. I'm discouraged right now from flagging things with reasons like "hey! a dev should look at this!"
    – durron597
    Commented Aug 14, 2015 at 19:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .