I used this word on purpose. I could write “I know” or just “issue closed is not fixed” but could I be 100% sure I’m right. I wrote “think” cause probably thinking is better than believing or using instinct 
That’s why I wrote about possibility to use notes. I can note that I think or believe that this issue isn’t fixed, write why I think so and add some screen or logs then someone responsible can open it or reply that my belief is worthless
Okay. You should be able to add comments on Resolved reports as of now. Only Closed reports will be read only (I guess/hope the devs don’t have an issue with that).
Ok, that’s good. Thx
We had 2 spam bots creating “reports” on Mantis the last 24 hrs, so I’m going to temporary suspend the right of anonymous user to create reports. Let me know if you think that’s not a very good idea.
I believe it may be very good idea, as sometimes we need to chase users who make poor reports for additional explanation.
We had a (small) strange thing happening with #338 : anonymous user was able to reopen it and add a note, although as per Permissions Report, as “viewer”, it shouldn’t be able to (and judging by the text in the note, I assume it was spam, though I’m not at my PC to check just in case if the issue reported there reoccurs).
The only thing I could see that can still be modified in the user access, was to also assign anonymous user to the VCMI project as “viewer”. FYI - none of us is particularly assigned to the project in a similar manner, so I can’t be sure if my change will eliminate the glitch, or on the contrary open the door for another issue. So I thought of posting this as a heads-up to everyone in case you see new strange things on Mantis linked to anonymous user.
Nevertheless, this looks to me more like a MantisBT bug rather than a settings issue. [size=75]// EDIT: Another MantisBT related seems to be the fact that anonymous user is shown as having its last visit in April last year. Clearly not the case. Once I’m back from holiday and have some extra time, I’ll check if these are known bugs to the MantisBT devs.[/size]
As for #338, if someone gets the chance to double check that it still works fine, pls move it back to fixed/resolved. Otherwise I may do it at a later date, once I get the chance to test it.
It looks like a bug in mantis. We should update to the newest version.
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:
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.
Regards,
Zam
Zamolxis: there are well known and long settled rules for open source development. One of them says that developers’ time is more precious than users’ (as long as they don’t donate money). There’s nothing stopping you from making kind answers and do searching that some gamer were too lazy to do himself, but believe me - such person would never ever contribute anything valuable to a project.
As an on and off visitor of this project I agree with Zamolxis. I do not say that by default developers should lose precious time with things that are not on their priority list, but sometimes it helps if they give a more meaningful/detailed answer. Or shift a little priorities to correct a game killing bug for 1,2 users.
EG. In my case yesterday! I filled a bug report about a crash at the very first fight of the game ( 1289 ). I was happy to see that someone was interested in helping me sorting this bug even if it was not reproducible on his side!! And it happened before a few months ago with a first day bug on map “the imp” that got corrected in 1-2 days I think.
Like Zamolxis said, communication helps a lot with not turning away players from VCMI. Especially non tech savy ones.
Fair enough. And thanks! I don’t have experience with open source projects other than VCMI. I only worked with Ubi on H5 and I also work with coders for my real job (for more boring software). Both are however cases of coders working on salary, so that changes a lot. They’re probably happy to boost their stats by marking “Fixed” a bug which at core was same as something they already fixed, but not implemented.
It was a suggestion, not a request or anything. And I think I stressed it myself in the end that devs can ignore it if it makes things less easy for them.
For clarification, I didn’t suggest they do “extra work”, just change the approach for similar work volume. Now they do 4 actions: Relationship - Duplicate; Status - Closed; Resolution - duplicate; Add Note - “Closing as duplicate of…” (which SHOULD be done for obvious dupes, where tester was indeed too lazy to check)
In my suggestion, for cases when bugs don’t look the same for the tester, it could be 2 + 2 actions, of which only first 2 have to be done by a dev: Relationship - Related to / Child of; Add Note - Same cause as… or Will be fixed together with… 3rd action would be Status - Resolved, but even I can do that (as long as I’m still around) when I see the other is fixed, based on their earlier Note. ‘Resolution - fixed’ is default so that’s a step skipped that noone will need to do. 4th action Status - closed to be done again by me in next release, when I check that things work (something which I didn’t manage anymore the last year or two, but due to temporary circumstances, so I hope to slowly catch up this year).
What I do see as potential annoyance for devs, is temporarily having more open reports. And if that’s bothering, it’s already enough of a reason for me to even **defend **the current approach.
My purpose was a benefit for the devs, just in case they also felt we could use more testers and wondered what can be done about it. But it could be that we’re still in the place that we just need more coders and that’s it, in which case current policy is indeed filtering out the less tech savy ones (who might create a higher number of redundant or badly described reports).
There is one problem with closed reports: they’re not visible with default filters.
This may lead to confused “why my report was deleted” complains (not necessary voiced on forums).
Maybe there is a way to change that default filter?
You do have a point. But from dev point of view this is a huge difference - duplicate usually means that fixing one issue will also fix another one. So there is no need for second report to be visible among unresolved.
Related usually means that both bugs may come from same areas of code.
I still would prefer one more duplicate to not reported bug that may look similar. Sometimes even duplicates are useful because they describe bug better than original report.
Probably this. I’d rather spend 1-2 minutes to check for duplicates of newly reported bug than have one extra issue in list.
Zamolxis: I’m not saying that your idea is flawed - however, any workflow changes should be supported by bug tracking system itself. You simply cannot say “lets not use this function, better proceed that way”. So any optimizations, additional flags/fields and other suggestions should be made to BTS, in this case - mantis. Or it might be better to use another system, like trac or flyspray, but this is entirely different discussion whether such change would be desired. The point is, your work is limited by tools you use, but you should not misuse them; avoid exploitation of any hacks, or you’ll break something (like reports).
Can somebody with access create two new categories?
Ha, just in time
What do you want to put in campaigns? Mechanics, GUI, both? Are there enough remaining issues to fill this category?
Just “Campaigns” group. There are quite few campaign-related issues but they don’t have any common category at the moment.
Right now there are 12 open issues that mention “campaign” word, with 5-10 that are actually specific to them. Not much but better to have these issues in completely unrelated categories.
Ok, done 
Hosting provided by DigitalOcean