"MarkS" wrote
reproducible. Reproducible does not mean every user has the problem, it means
1 user can reproduce the issue over and over given the same set of conditions and show it to TS/Developers rather than a random event.
------------------------------------------------------------------
I did not say that reproducible means "every user HAS the problem" [emphasis added]. You can't refute what I said, if you misrepresent what I said. I suggest you read my post again.
But one user who has the same problem all the time is not reproducing the problem . One good example: data corruption. A user with data corruption may consistently experience a specific problem - which no one else can reproduce since they do not have that corruption. Even multiple users may have corruption that causes a specific problem - and that condition is not reproducible, since no one knows how corruption occurs (so no way to "reproduce" the corruption), nor what corruption causes what problems ... so no other user, not already experiencing that problem, could reproduce it.
There are several long lasting Quicken problems, reported by many users, that have never been "reproduced" (despite the attempts by many other users to recreate the problem) - which is one of the reasons why they are "long lasting problems".
The steps you took did not qualify your problem as reproducible. Unless others using the exact same software, in the exact same environment, with comparable data, can cause the problem to happen (especially when they were NOT already having the problem), then the issue is not "reproducible". That's why users are asked to provide their operating system, year-version, release, Preference settings, as well as (sometimes) their monitor and screen resolution, some data samples, what automatic backup they might be using, etc. The idea is to eventually make it possible for other users with the same operating conditions to "cause" the problem to occur ... when those other users had not been experiencing the problem.
To "reproduce" a problem is not the same as to "experience" or "have" a problem: "reproducing" requires that the problem can be "caused" by someone not already "experiencing" (or "having") it. Which in turn requires identifying the conditions and steps necessary to cause the problem to occur.
By the way, in case you also misunderstood this: the fact that a Quicken (or any) problem is not reproducible does not mean that it is not a real problem. And it doesn't mean it's not a bug. It does mean that the odds of getting the problem fixed (either by modification of Quicken where applicable, or other means) is significantly less likely. Once the steps necessary to create the problem are known, the probabilities for addressing the problem increase. In the short run, sometimes knowing what causes a problem offers insights into a workaround for the problem. And in the long run, when a reproducible problem is caused by a Quicken bug, or an intentional Quicken policy; the odds of getting changes made by Quicken increase.
[If the software developers are already experiencing a problem, then reproducibility is largely a moot point: they will already have the ability to analyze the problem and find its cause. Reproducibility is only necessary so developers who do not see the problem (and have not found a way to cause it to occur) can know the conditions and steps necessary to cause the problem to appear on their computers. Secondarily, reproducibility may help a user get confirmation from other users that they are facing a problem caused by Quicken, rather than some other software (such as an automatic backup program, for example), user-misunderstanding about how the software works, or user error. ]