Status: Not By Design

Question

In light of the recent change in vote ordering, a certain aspect of the design process for SO has been highlighted. It seems that certain features, while present in the system, are considered by the developers to be accidental (see this comment thread). In this instance, the secondary ordering of answers by last change was "completely accidental, and was never by design."

Therefore, it seems the developers feel justified in making changes more arbitrarily than they would with parts of the system that were explicitly purposeful and by design. Since it was never intentional and certainly wasn't intended to be permanent, why not change it once a good idea comes along?

While I have no problem personally with the developers using whatever system they see fit to prioritize and implement code changes, I can see how it is frustrating for users (particularly those who frequent meta) to have their opinions weighed against the (unknown) original intentions of the developers.

Should the developers be more up front about which features may change at any time with little discussion, and which are carefully considered elements that will require extended consideration? Is that even possible?

Or is this something that just has to be accepted as part of the package when dealing with a system as complex as SO? After all, not every piece of code and layout is going to have been carefully considered. Therefore, shouldn't we expect that some features are subject to change at the sole discretion of the developers?

At the end of the day, all features are at the discretion of the developers. This is not open source, they own the code base. But I think many people here on meta would like clarification on their role in making these decisions.

Answer 1

Let me preface this by saying that this post is not about the sorting of answers specifically. I do not want to discuss in this thread whether or not it is a good idea. That has been done in other questions.

I think this issue actually highlights the flaw in Meta as a bug-tracking tool.

In the eyes of the developers (this is not official, this is my interpretation), they were fixing a bug that existed in the system. On typical bug-fixing issues, you do not have to go to the community, i.e. if there is a typo in an error message, you should just fix it and move on.

However, in this case the 'bug' that they fixed turned out to be near and dear to the hearts of many users.

Many people have made a hubbub about the fact that the community was not consulted, which doesn't really make sense to me because they did not anticipate that there would be controversy. I think it's too early to characterize 'the way they handled the controversy' because, as all of us can attest to, it's not over yet.

Meta is filled with hugely diverse questions. A lot of them are "how do I?", "feature requests", "bug reports", "I want to complain about xyz" and then a variety of things which are just wildly off-topic. In all of this, it is hard to get a handle on which questions and which pieces are 'code-actionable'.

If there was a way to keep track of a list of 'prospective functional code changes', then the community would be able to characterize their response to these things beforehand.

We already have an 'In-Progress' tag, but that only refers to the code changes which happen to be related to meta questions.

Suggested (possible) implementation

Every time you guys come up with an idea, or one of the StackOverflow Valued Associates makes a check in, you could log it on MSO with a Moderator-Only "In Next Release" tag.

Create a link that goes straight to the "In Next Release" Tags page. That way the community will have a very easy way to know exactly what changes are possible to happen in the next release, and they can discuss them.

This would also serve as release checklist, because once a deployment has occurred, you can change the tags one at a time to 'status-completed' once you have verified them in the production environment.

Hopefully, this will keep us from having venomous discussions after a deployment, and switch them to heated discussions prior to deployments. Oh, and this would only apply to changes that have a functional effect on the front end. I wouldn't expect any "performance tuning" type stuff to appear there, because it does not affect the features/bugs of the site.

Answer 2

I personally like the idea of feature changes being presented here on Meta first, with the community here giving feedback ont it, because that way I could have a part not only in the running of the system, but in the system design. (Architecture astronauts, anybody?)

I see two possible problems with that approach:

1. Meta is already perceived as being elitist by some new users. This would add to that perception. (Even though that perception is clearly wrong IMO)

2. The biggest challenge for the developers is to find a solution to the find S[OFU] through Google use case. Since we knwo the S[OFU] engine for quite some time now, we are by definition the worst group of people to judge how a new user perceives the site.

Anyway, having a notice here on Meta when a feature change is released would be very nice.