Resurrecting this thread for a MantisBT administrative observation.
I’ve seen the last couple of years several cases of new users who joined Mantis, created a couple of reports, and then kinda vanished (or at least became inactive). Coincidentally or not, many of them had, among their very few reports (if not the only one), a report which was immediately closed as “dupe” or “no change required” or similar.
Maybe pure coincidence, it can be seen as “no big loss” especially if they were to continue with such reports taking devs’ time without much added value.
But I’m gonna play testers’ advocate here and give them the benefit of the doubt. I understand why (almost) all were closed as such from a dev’s perspective, with mainly efficiency in mind and nothing personal, but I’m gonna try to give you also a tester’s perspective, of one with less technical understanding of game mechanics (at least IMO).
What if they were put off by the way or the fact that their reports were closed as such? Picture this: a newcomer gets interested in the project, does his (or her) homework to read the release notes, install properly, then go to Mantis for reports. Let’s say he finds a bug with Underground Gate. He takes his time to search “underground” and “gate” to avoid giving you dupes, and then takes his time again to write the report itself. And then ‘bam’ someone closes it as ‘dupe’ of some other report that says something about magic mirrors. He starts by wondering “why” “but they aren’t the same” … then slowly figuring out they kinda have similar mechanics (at which point a tiny bit of the magic of Heroes dies, when realizing it’s technically the same, but drawn differently to give him the illusion of something else). Then comes the frustration of realizing they just wasted like 1 hr of their life for nothing, and that the experience might very well repeat itself, as who knows how many other game aspects have behind the same mechanics that are not as obvious at first sight. If they get that far, others might remain confused, wanting to ask the “why”, but with the closed report preventing notes/comments, they’re left frustrated (and perhaps embarrassed to open a some topic on forum just for that, to not look stupid).
And so on… I have in mind few other scenarios that may lead to demotivating a tester, but you got the idea.
I’m not suggesting we should stop closing reports with resolutions which brands them as useless. But maybe we can be milder in the approach / labels applied, giving the tester some sort of recognition for their efforts (or at least not something that looks like punishment). Not in all cases. A second report of crash when casting Haste, is clearly a dupe and they won’t mind being told that. But in cases like following:
- two crashes of totally different behavior and circumstances, which turn out to have the same root cause, could be just branded “related to”
- same for bugs on different objects with similar benefits (the recent example with Temple and Oasis comes to mind)
- there’s an old bug about horde buildings (or creature banks), and someone reports a bug with Griffin Bastion (or Conservatory). One could be even paranoid in his good will of avoiding to bother you with dupes, and try all possible misspellings or translations of “griffin” and “bastion”, and then also “creature”, “generation” and “boost”… and would still not find the one about “horde buildings”. So such reports could be labeled as “child of” instead.
Benefits for the tester: the rewarding / encouraging feeling of being useful
Benefits for you: maybe more testers, and maybe appreciation from them for how “fast” you fix some issues, or for the gentler way of teaching them the relation between items, when Resolving reports with comment “same cause as #123”, instead of Closing with “duplicate of #123. closing”
Disadvantages for you: Feel free to point them out. Perhaps you’re perfectly happy with the current system, which may even be important for the accuracy of certain stats you’re keeping; and following my suggestions would mess that all up and make things less comfortable for you. If that’s the case, then forget about it. A project has better chances of success with more (happy) coders, than more testers. So priority remains the approach that makes your life easier. The suggestion was just in case it’s all the same for you in terms of effort and if you also feel we could use more testers.