# ASKDBSTALK: New Rules clarification



## DonLandis (Dec 17, 2003)

1. In the case of a bug that causes a destructive failure, a DBSTALK member posts it here. How will Eldon or support people here fix his 921? I believe a destructive bug is only fixable by calling in to E*. Are we to call in this destructive failure and not report it here to prevent a duplicate report being filed? Suggestion: CSR's should be asked to do the same thing; i.e. when you tell them you already reported the bug using proper protocol on the forum they should know not to duplicate the report. 

2.  The new rules doesn't seem to allow for bug frequency or quantity of users experiencing the same bug to be reported. Consider that member #1 reports 7 bugs in 7 report threads. As I understand, only member #1 may post further comment about that bug report. It becomes his thread. If member #2 also experiences the same bug, he is not permitted to post it. 
If this is the case how does Eldon know if a particular bug is wide spread, isolated case or just a few cases? Mark, can there be some way for a vote count in each Bug report, like a poll, where other members could check off, Yes or No as to whether they experience the same issue but then not be permitted to make commentary? Suggestion- In the traditional 921 support forum, the same poster needs to post a second thread of the bug for discussion and a new rule requires all bug discussion threads be of a POLL nature restricted to : I have this bug, or I don't have this bug. This, while not an accurate count, would give a general feel for the frequency of the bug among members reporting in.


----------



## David_Levin (Apr 22, 2002)

I agree with both comments above. "Me Too" posts in bug reports are critical to decide between a bug and user/hardware error.

Also, not reporting a bug to Echostar does nothing to help other suckers (users) who don't read these forums and just call customer service for help. It also may potentially make E* think the 921 has fewer bug then reality.


----------



## Mark Lamutt (Mar 24, 2002)

I have given some thought to both of these issues, and will continue to do so, and will continue to tweak the system to make this as effecient as possible. And of course, I'm always open to suggestions.

For #1, I would say that it's a judgment call on the users' part. All hardware failure situations obviously have to be called in in order to get the 921 swapped out. For now, I'm going to tweak the bug posting rule and ask you to include the severity of the bug as it affects your use of the 921. This one is just a request on Eldon's part attempting to do some streamlining of the process. I would ask that if you do call in your bug reports to tech support that you explain the problem as close as possible to what you post here, or that you post here as close as possible to what you explain to tech support on the phone so that it can easily be seen that it's not two different issues. The ultimate goal is to make sure that you get the bug that you're seeing to the developers without it being modifed by going through 3 or 4 sets of other hands before it gets to them. 

For #2, I agree that it's definitely a problem. But, it's a much bigger problem to have a bug reported, and then lots of discussion spread over 4 or 5 pages, with other bugs buried in the discussion. Those bugs tend to get missed more times than not because of the time required to read through all of the discussion. And then when it gets to the point of much of the discussion calling for Eldon's heads to be prominately displayed on pikes along side of the road leading to Dish HQ, why would they want to continue reading through all of that to try to catch any other bug reports buried after it? That's the reason for not allowing anyone but the original poster to post again in his/her bug report thread. 

I like the idea of forcing all of the posts in the bug report thread to be a poll, but I don't have any way to do that on this end. And, as at least some of the posters in this forum aren't going to bother to read the rules anyway, I don't see a way to make that work. 

For now, if the bug is a BIG one that highly affects your operation of the 921, and you see it or something similar to it already reported, read the report and if you have another take on it, or have additional information to add, post your own bug report, but use the same title or a very similar title as the other poster used to make it obvious that you're both talking about the same bug. Or, start your own discussion thread in the support forum, linking back to the bug report thread for reference.

EDIT: David and anyone else - I have no way of limiting user reply posts to "me too", and I don't have time to edit and delete 4 out of 5 posts that will be left in there. I want suggestions on how I can pull this off, because I'm not seeing a real workable solution to this problem at the moment.


----------



## John Walsh (Apr 22, 2002)

on every but post the person composing this message should include a poll in it that simply states

Do you experience this bug

Yes


No


----------



## Kagato (Jul 1, 2002)

I agree with Don on calling E*. They are a 13.35 Billion dollar company. They have the ability to staff and streamline process to deal with this. I'd estimate that this board saves E* at LEAST 25K each month just from people who'd be calling support. 921 user by the way go directly to Advanced Support.

That being said my concern is getting the box working. If the 921 is critially down or lame I'm not thinking twice about calling the 800 number.


----------



## SimpleSimon (Jan 15, 2004)

It's such a sad state of affairs that there's no way to call E* to report a bug and tell them it's DBSTalk Thread #xxxxxx and have that datum passed through the system.

Alternatively, E* could report their report # back to the requester and they could post it here. Very, very sad.

At least Eldon is doing something. Now one more step is needed. That is for them to post back into the bug thread once they know something about what it's going to take to fix it.


----------



## Mark Lamutt (Mar 24, 2002)

SimpleSimon said:


> At least Eldon is doing something. Now one more step is needed. That is for them to post back into the bug thread once they know something about what it's going to take to fix it.


What information do you want to see them post back?


----------



## David_Levin (Apr 22, 2002)

Mark Lamutt said:


> What information do you want to see them post back?


Do you really need to ask?

1) Failure confirmation/repeated
2) Fix Status (low priority, in progress, emergency release planned)
3) Estimate date/version for fix
4) Fix Completed


----------



## Mark Lamutt (Mar 24, 2002)

Yup, I do need to ask. 

I can't post that information when I know it because of the NDA. What makes you think that Eldon would post it publicly? Or that Dish would even let them? 

Believe me, I would absolutely love to see that level of feedback coming out of the pipeline, but I can't see it happening.


----------



## DonLandis (Dec 17, 2003)

Yes, Mark, I understand your dilemma with people not following the rules.  But, as I understand it, the whole purpose of this special section is to streamline the process of Eldon reading and at a glance, get the concise list of user reports without the need to wade through long threads. I don't think offering that everyone can post separate threads now where many will be reporting the same bug will accomplish what you want, and what Eldon wants.
If the rules are zero tolerance, and each poster MUST post the Bug Report as a 2 answer poll. Then all who post to that bug thread may only read the originator's bug report and click on one of the two answers in that poll. All other posts will be promptly deleted, not moved but deleted. I understand the forum software does not permit the thread to be open to vote, and not be open to post, so that would need to be a rule. And, what if a poster violates the rules after repeated warnings?, do I need to ask that? 
Another zero tolerance rule could be that any duplicate bug reports, that are truely duplicate bug reports will be deleted. 
The poll will, I believe, be the only way to build the information desired without huge proliferation of duplicates that require a tabulator full time and would be a way to measure the commonality of the bug at a glance, and the description. 


If I were Eldon, I would want the list as small and non-repitious as possible but would want to know if 1 had the bug or 35 had it or 75 had it. 

One more thing and maybe you plan to do that, It might be a good idea to purge the bug reports in that forum section with each new update version, archiving the past versions reports for historical reference only.

I also agree that It would be nice to have some feedback but in reality, none of the beta programs I have been involved with were very good with developer feedback to the testers. At best, we would get a list of new tests they would like to see run without comment on your report. Only once with a piracy detection idea I had did the developers hold a meeting to brainstorm implementation of it. My idea was actually implemented into the software and worked well. More important to me is that Mark may report back to us that this new approach is working and will result in more fixes in a more timely manner, followed by action that what he reported is true. Don't need the specifics, just want results.


----------



## David_Levin (Apr 22, 2002)

eldon feedback:

The last tek forum was very popular becauase they for once took the tuff guestions. People appreciated the honesty.

I suppose it's asking too much to expect feedback, but I think it would quiet things down if we knew what was going on (some of the bugs have been around for a long time).


----------



## jsanders (Jan 21, 2004)

This solution isn't perfect, however, it does serve a purpose. The number of threads that Eldon has to read is reduced. The reason for making only moderators or posters able to reply to a bug report thread cuts downt he chaff that Eldon has to wade through. It puts responsibility on us end users to create a discussion thread for the "Me too" things. More importantly, the discussion thread allows us to hash out details and then whatever pertenant information precipitates from that discussion, the author of the bug report adds that to the list. Let's say, for instance, someone adds BUG REPORT L187: Loss of OTA channel. Then someone else reads that report, has questions about how to reproduce it, and starts a discussion thread to draw out the author. Out of that, the author learns that more information was needed in how to reproduce this particular bug. It is now his responsibility to post that pertenant information into the bug report. It is now our responsibility to make this work, we have to keep that in mind. We have to filter ourselves and put whatever precipitates from a discussion is what we post in the bug reports. It isn't perfect, but if we are disciplined, it will add benefit.

The "me too" is important, however, it isn't as important as writing a bug report that Eldon can reproduce. If they can't reproduce it, then they can't fix it, regardless of how many people experience the problem. Let's see if we write stuff that is useful to them.

It would be great if we could get some feedback stating whether a bug is reproduced, but it isn't going to happen. There can be legal issues involved. For instance, I wrote a bug report that the ratings lock didn't work under certain circumstances. It was fixed in L185, and it isn't fixed in L186. They can't state that such a bug was fixed at one time. Why? If they state that it was fixed, it is admitting that it was broken. Admitting your ratings lock is broken can lead to a lawsuit by someone. I'm not that person, but some people do stuff like that. Because of that type of person, we aren't likely to get a lot of feedback.


----------



## Redster (Jan 14, 2004)

For the "me too" option. couldnt the person that creates the original bug report, start a discussion item in support forum with a poll,, "yes" or "no" (cut and paste would make this easy). I notice the poll does count numbers. Then say every couple of days , the original poster could update the bug report with # of users experiencing the same issue ?


----------



## SimpleSimon (Jan 15, 2004)

I'd settle for a simple: Yes, we see it's a bug and will work on it.

This NDA and legal crap is nothing but smokescreen to hide behind. No offense to Mark - I'm talking about E* forcing that.

Been there, done that, got a drawer full of T-Shirts, including one that says "I got the marketing manager fired because of his 'we are perfect there are no bugs' attitude".


----------



## Kagato (Jul 1, 2002)

Honestly I'm not understanding E*'s desire to have an official forum, and not post feedback. In particular with the local OTA issues. After all, they are willing to do a LIVE TV show and answer questions, but you can't get a little feed back here and there on the forum? It's just not logical.

I think Dish should look at the model Compaq uses for their forums. Lower level techs quicky screen issues. They post links if it's a dup or known issue, as well as indicate when something needs escalation. I know for a fact that ADV support at E* does standard IT helpdesk/desktop support between customer calls. $13.35B company, selling an expsive product which has issues that need to be addressed. How about dedicating a tech person or two to hit the boards during the slow times.

It is in Dish's best interest to have good community ties. HD isn't going away, and it will become more and more key with every month.


----------



## Scooters (Mar 15, 2003)

I just posted this under another thread, before I saw this one. Here is a suggestion on Eldon Feedback.

http://www.dbstalk.com/showpost.php?p=277427&postcount=34


----------

