In several scenarios, including two today (the one with the badges and the one with the comment focus), we have had bugs set to simply because the fix has been checked in. Just because the code portion has been completed does not mean the work is done, and this can be confusing for users who come across the same problem. Until then it really is or maybe a tag that doesn't yet exist (status-checked-in?).

Particularly in times like this week, where the stability of the system is a priority, I don't think this status should be set merely because the code has been checked in - it should happen when the code is actually deployed and verified. Currently the devs are being very good about telling us that the code is done but they're not sure when it will be deployed, but I think that is because of the stability issue.

  • 2
    I agree. This bug hasn't been fixed in my chrome and it has [status-completed]. [status-planned] should be appropraite – Walker Nov 25 '13 at 21:09
  • 3
    Down-voter, could you explain why you think a bug fix that hasn't been deployed should be marked as "completed"? In my job, a bug isn't fixed until the end users are no longer affected by it. – Aaron Bertrand Nov 25 '13 at 21:11
  • Why is the stability of the system a particular concern this week, as opposed to any other week? Is there something going on I don't know about? – TRiG is Timothy Richard Green Nov 25 '13 at 21:12
  • @TRiG there were some issues with the database servers over the weekend I believe. – Aaron Bertrand Nov 25 '13 at 21:12
  • Wow! Great minds think alike! – ShaWiz Nov 25 '13 at 21:15
  • 4
    So what are you proposing? That a dev not only need post an answer, but also keep track of the question so they can go mark it as completed whenever that change actually gets deployed? That seems like a lot of effort for a dev. Anyone could easily figure out that the fix is not yet live by reading the answer. – animuson Nov 25 '13 at 21:16
  • 3
    FWIW, the tag wiki explicitly states that it is used this way. – Geobits Nov 25 '13 at 21:16
  • 2
    @animuson your argument works against you. So when the code is deployed, do they go update the answer? How on earth do they keep track of that? If they don't update the answer, then a reader might assume that the fix is forthcoming, and just think that the issue isn't happening to them right now. shrug I think it should be pretty simple to tie a code change in source control to the bug report / question ID that it came from... – Aaron Bertrand Nov 25 '13 at 21:17
  • 5
    @AaronBertrand Well you can compare the revision he posted to the revision in the footer of the page... Why would the answer need edited? – animuson Nov 25 '13 at 21:19
  • 1
    Looking at the tag and one of the steps says "a bug has been fixed", now does that mean that the code (and other assorted changes) has been done to fix the bug? Or does it mean that the fix has been completely deployed and the end user can see the results of the fix? What I would assume is that it means the bug has been fixed in code and it may or may not have been deployed depending on the what is all involved in getting the fix out. In the long run I think its better to know a fix is complete even if it isn't live yet. – Joe W Nov 25 '13 at 21:20
  • 1
    @JoeW You could just, you know, read the second paragraph of the tag wiki. "This tag is added when the changes are checked into source control. Actual deployment generally happens every 24 hours." – Stijn Nov 25 '13 at 21:21
  • 2
    Folks, I am perfectly capable of reading the tag wiki. That doesn't mean I have to agree with it. I also suspect that a small percentage of even the portion of users who have found meta even know that the revision number is at the bottom of the page, never mind know that - just because a dev has stated in an answer that it should be deployed in ver x.y.z - it actually has been included in that revision. – Aaron Bertrand Nov 25 '13 at 21:22
  • @Stijn I was just going off the hover text of the tag but that does go to what I was getting at of having the tag when the fix is done not when it gets deployed. – Joe W Nov 25 '13 at 21:24

This isn't generally a problem. The devs around here are generally very good at mentioning a specific timeline as to when a completed change will roll out. Usually, they even mention the specific build number it'll be fixed in. And builds normally roll out pretty quickly; they're just being delayed today by the SQL issues. Which was already mentioned on the issue you pointed out, in the answer Sklivvz mentioned.

Marking the issues when the work is done is the right thing to do. It lets the original reporter of the bug know that their report was useful, and has been acted on. As @animuson pointed out, it lets the developer who fixed the issue move on, without needing to go back and update when the build deploys. Importantly, it also lets everyone else know "This bug is fixed, so if you were planning to put a bounty on it to make us pay attention, there's no need!', and honestly, unless the Stack Exchange SQL servers are acting up, builds can roll out pretty damn quickly, especially here on Meta.

  • 1
    Then there should be another tag to signify when the code has been deployed. As end users we don't really care that the code has been checked in... – Aaron Bertrand Nov 25 '13 at 21:21
  • 4
    @AaronBertrand I do. It means that 99.9% of the work involved (finding the bug, working out how to fix it, creating the fix, testing the fix, etc.) is done. Certainly, everything non-automated is done. All that's left is to wait. – Billy Mailman Nov 25 '13 at 21:22
  • Devs could make everyone else know that the bug is fixed with another tag (status-checked-in?), so I don't think that that point is very important. And, on the other hand, "SQL Servers" are acting up apparently – Lamak Nov 25 '13 at 21:38

You must log in to answer this question.

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