9

I understand that requesting features towards Stack Exchange Inc. works like this:

  • you write a question-request here on MSE
  • the community votes, and adds more thoughts, concerns, enhancements, ...
  • someone, somewhen makes a decision. When the decision is "no, won't happen", then the story ends there. If not ... there is no clear feedback when/how that request will be picked up. Maybe someday, the new feature is just there, or it gets announced as experiment. But the user making the suggestion, and the community statement "we like this" ... has no idea when that is, and how many other features have a higher priority at any point.

The voting mechanism makes sense, to get an understanding of the priorities that the community sees.

But these days, when you do agile software development (and SE Inc. wants to be agile, see here for example), shouldn't there be some backlog kind infrastructure, too?

In other words: in 2019, there are tools like Trello, Jira Agile, Jira Portfolio, or Pivotal Tracker, and many others. I assume that SE Inc. is using such a tool to plan its activities.

Wouldn't it be great if the community related parts of their planning data would be publicly available to us?

According to SE Inc., they intend to listen to us. Being able to see how feature requests progress on their development planning would be a really great way to give the community feedback about ongoing work/activities.

Edit: I do not consider Allow public tracking of feature-requests via view into Stack Overflow's ticket tracker to be duplicate that matches the intent of my question: defect trackers focus on low level information, such as "who touches module X at which point in time". I can understand that a company isn't eager about disclosing such internals. I don't want a level of detail that enables posts like "Look, SE Inc. engineer X takes double the time compared to Y, when they on community requested feature, why is that?"

What I ask for is to create transparency on the project planning side of things. Including "effort estimates", and appropriate information about "capacity" on the other hand, and the ability to quickly answer questions such as:

  • What is worked on right now?
  • When should that thing be completed, according to the plan? ...
Improve this question
14
  • 1
    How is this list not a "backlog"?
    – ChrisW
    Commented Nov 11, 2019 at 8:43
  • @ChrisW Because It doesnt tell you anything when a feature request will be picked up. Or what the estimated effort is. Or when it is planned to be delivered. Let me ask a counter question: would you accept that "tag link" as backlog for your daily work within your company? Or do you think that open/public planning isn't an essential part of "agile" practices?
    – GhostCat
    Commented Nov 11, 2019 at 8:54
  • 1
    But how relevant would it be to us to know what will be implemented. Especially when we know the usual timeframe for something to be implemented is 6-8 arbitrary time units. Also what good is it to know a list of upcoming things that change every week or so, as other priorities come in. That will only lead to false expectations.
    – Luuklag
    Commented Nov 11, 2019 at 8:57
  • 3
    @ChrisW: You mean this.
    – Himanshu
    Commented Nov 11, 2019 at 8:58
  • 1
    Yeah, would be nice to see roadmap in trello, for example. But there is no sense, 'cause SE usually breaks deadlines :D
    – Suvitruf - Andrei Apanasik
    Commented Nov 11, 2019 at 8:59
  • 1
    meta.stackexchange.com/q/58644/369802 < Old, but seems related.
    – Tinkeringbell Mod
    Commented Nov 11, 2019 at 9:02
  • 1
    @SuvitrufsaysReinstateMonica One can keep complaining about a broken past, or one can work on ideas to get to a better future. One aspect of public planning is exactly that: there is transparency what happens to agreed-on features.
    – GhostCat
    Commented Nov 11, 2019 at 9:06
  • 1
    @GhostCatsaysReinstateMonica there is the reason behind all this - they have really small team, AFAIK. But in general, I agree, transparency is a good thing.
    – Suvitruf - Andrei Apanasik
    Commented Nov 11, 2019 at 9:08
  • @hims056 Same question: if that would be the basis for your daily work, would you be happy about it? So why do you think it should be acceptable for this community?
    – GhostCat
    Commented Nov 11, 2019 at 9:09
  • Time since previously asked should not be a factor when deciding whether a question is a duplicate of an older one. To make the case for it not being a duplicate on other grounds you could start your question by showing that you are aware of the earlier possible duplicate, and explaining why you think that it is not one.
    – PolyGeo
    Commented Nov 11, 2019 at 10:46
  • See here for an explanation that "there are announcements of feature request progress", and the right column for more links. There's a blow-by-blow page that's alluding my search (and time available) ATM, it lists each fix as it is made (well, shortly thereafter).
    – Rob
    Commented Nov 11, 2019 at 12:25
  • See the official Changelog, otherwise you can use the appropriate red moderator only tags in a search to look at the pipeline. Examples: status-bydesign status-completed status-declined status-deferred status-norepro status-planned status-reproduced status-review
    – Rob
    Commented Nov 12, 2019 at 7:55
  • @Rob Again: I am asking for SE Inc. to provide a comprehensive view into their planning. A list of already delivered features ... isn't that, at all. Tags that express "current status" is part of the planning and execution, but it isn't comprehensive. If we consider the community to be somehow stakeholders here, we should ask for more than "go look at tags".
    – GhostCat
    Commented Nov 12, 2019 at 8:08
  • 1
    We had What features did the Community Team discuss, have implemented, or have denied last month? for a while but that got rather depressing for all involved ... also : meta.stackexchange.com/questions/305560/…
    – rene Mod
    Commented Nov 14, 2019 at 11:16

1 Answer 1

Reset to default
2

The Director of Product Marketing provided an answer (elsewhere), and I think the message is really clear:

We have a robust roadmap and we are selective in asking the community for feedback on specific releases.

SE Inc. makes the roadmap, and unfortunately, their actions tell us that they do not regard the community as stakeholders in an Agile sense.

Thus it is not reasonable to expect SE Inc. to live up the suggested working hand in hand.

Improve this answer

You must log in to answer this question.

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