Moving missing features list to bugtracker

Right now we’ve reached stage where most of H3 features are supported so sometimes finding missing features to work on takes longer than implementing them.

What I’d like to do is:
1)Add all missing features as reports on Mantis. This includes Google Docs list and forum thread:
spreadsheets.google.com/ccc?key= … pLe4raNAWA
[forum.vcmi.eu/t/missing-features-functionalities/160/1)
These links were useful previously but right now looking for 1-2 missing features out of list from 100+ element isn’t very productive.

  1. Create master issue, mark it as sticky and set it as parent to all missing features that can be noticed by regular player.
    This issue will also work as answer to regular “What to expect working?” question.

What about missing mod features? Or mod feature requests?

For example, hero specialties like Eovacii’s from HotA, which exists in VCMI.

Such things should be scripted.

I was just asking where can it be reported, since they are developing the cove mod. Scripting system is not implemented yet, how do you think the system should look like?

I support this proposal. Bugtracker is just better tool for such task and we should keep all the issues and tasks in one place for better management.
The only problem I foresee can be people posting requests on bugtracker instead of forum board… but right now they do quite the opposite, so maybe it’s not an issue :wink:

I think that future requests presence if tracker is good of itself, but discussion should be on forum.

Warmonger,
Yeah. Right now I’m not sure what to do with mods. Features like aforementioned Eovacii specialty certainly should wait for scripting (instead of bug report). Bugs in abilities implemented in code should be reported on tracker no matter where they’re coming from - mod or H3. These two scenarios are clear.

But what to do with bugs in “our” mods? Like Cove, Witchking arts and such? I’m leaning towards forum thread for feedback/bug reporting but if there will be better proposals…

AVS,
IF these feature should be implemented in code - OK. But for most cases this is something we should leave for scripting.

Bugs in “our” mods should be in bugtracker. We already have category “Mods” and also may add separate project(s) for such things.

I’d also wait for a confo from Tow. The purpose of VCMI was to create an open-source platform for any other mods. And we’re close to that. But once mods are supported, the traffic on the forum & Mantis may grow exponentially. Is Tow’s domain subscription able to absorb up to how much extra traffic? Perhaps this was already discussed (I’ve been away for quite a while), in which case my apologies, else this may have to be checked.

Then there’s also the risk of Mantis getting a bit messy or confusing with reports for this or that mod (not always clear if supported). VCMI is “WoG recreated”. I’d say it definitely should support H3+WoG related reports. Next to that, maybe it can also support mods for which one or another of the VCMI Team Programmers has committed to support. However the rest may better be discussed here, or even on the community forums (CH, HC…).

An alternative would be opening other Mantis portals for different mods (on same server, or others)

@Ivan et al - for the time being, how about a “master issue” / sticky on Mantis, with simple subject: “All H3 (original) missing features” as parent to all Mantis reports of H3 features still missing (to be transferred from “the list” if not yet there). But other than parenting that, the description should contain the following, to guide people to the right place:

  • A link to another “master issue” report - “All WoG missing features” - however that will not be stickied, until all H3O features are done
  • A link to other “master issues”, for each mod officially supported by VCMI Programmers
  • A link back to the forums, for all mods not yet supported
  • And perhaps also a link to another “master issue”, which should parent all no-harm feature enhancement requests (that is features improving the game experience, without altering gameplay), e.g.: requests for new hotkeys, QuickSave/Load function, new resolutions, etc.

None of the other “master issues” would be a sticky, to keep focus on the current priority. Only, as said, once H3 is fully replicated, the WoG parent report would replace the other as sticky.

Let me know what you think about it, and I could set something like that up.

I doubt that growth will be that big. Besides - by “our mods” I mean mods made by somebody from our team, not all mods for vcmi. Bugs in any other mods should be reported to author and not to bug tracker.

I’m hoping for more organization actually. Right now a lot of missing features reports are lost in bugs and proposed features. Keeping them in one place (linked to one master issue) should help with that.

In general - I like that but I’d rather keep 3rd-party mods from bugtracker at least for now.

To inform players about missing parts I’d rather use a wiki page than bugtracker — it should allow us to present information in a more clear manner and there aren’t that many missing parts to make updating an issue. We already have wiki.vcmi.eu/index.php?title=TODO_list though it became developer-centric.

As for the moving missing features and enhancement requests I have mixed feelings. I don’t want bugtracker to turn into a place where people post their feature suggestions. Still, I see the issue with the current feature thread — it is just unmanageable.

I’d consider a compromise, like requesting people to post feature/enhancement requests on the forums and then let the developers decide whether it is feasible and within the project scope — and then add it to the tracker (if it is accepted)?

To start with it could be done with the features thread: split all bugs into categories:

  • missing OH3 features
  • missing WoG features
  • feasible enhancements (not altering game logic or totally no-harm)
  • small changes to the game logic (feasible but should be optional)
  • everything else

First 3 categories should go to bugtracker, while I’d leave 4 and 5 on the forums, possibly in a separate threads, with new lists.

It shouldn’t be a problem in predictable future. Server available traffic is used about in 50% and VCMI is one of a few pages I host.
We can always move downloads to some external service (like sourceforge) it it becomes a significant burden.

Do we really need master issues? We already have bug categories and we can create filters upon them. With master reports one has to set proper relationship for each of such bug, it sounds to me like an additional step that doesn’t provide any new information.

+1.
Bugs in everything we maintain (engine, mods and so on) should go to our bugtracker. 3-rd party mods bugreports should go their authors.

One problem with using wiki to show current status is regressions e.g. Angel Wings. This is why I suggested to use bug tracker where generation of such list can be automated (filters). If wiki will be kept up to date - then fine with me.

Definitely. Moreover - when I went through it I found at most 10 still missing features. Out of 7 pages with 100+ “reports”

IMO we need some separation between bugs, missing H3 features and new features. I think we can do this either as master report that will be more easy to notice (sticky) or as more flexible tags (in this case - list of tags should be visible somewhere). Creating categories that will largely duplicate existing ones is not a good idea.

There is also big group of feature requests / bugs related to mod system and bonuses. Mostly the things that logically could or should be working, but turned out to not work as expected. it’s good to write them down and take into consideration during bugfixes or mod system improvements, as well as brand new features.

Can you write this down somewhere like in todo list? Especially mod system issues. I know that system is not perfect but such list especially if made by modders would be great.

Huh… What is the difference between a bug causing feature to not work properly (or at all) and missing feature that was never implemented? I don’t think that players care about that. Do we want to provide information “what hasn’t been implemented” or “what doesn’t work”?

The issue as I see is rather differentiating between big issues that player should be informed before playing and list of hundreds of smaller issues that we can’t expect everybody to read. Being a missing feature doesn’t mean it is worth of attention. Being a bug doesn’t mean that players shouldn’t be aware of it.

Right, categories are not a thing for this.
We can still either use severity (we already have “feature” severity) or tags. Tags seem most flexible.

As I see Mantis offers list of tags in the View Issues filter options.

Writing new code vs fixing existing.

Or at least we should clean bug tracker from several year old non-reproducible bugs (+ recheck some others), remove new features that are unlikely to be implemented and so on. I see quite a lot of those starting from ~3rd page.

… which is used for both H3 features and newly proposed :frowning:
IMO all missing features should have minor\major severity and keep “feature” for well… features.

Missing H3 features should have higher severity and/or higher priority, because there is no difference between missing and broken original feature for users.

I can do any of the following:

  1. Go through the Missing features topic, and summarize in 1 post all that is not yet implemented, broken down in the categories mentioned by Tow:
  • missing OH3 features
  • missing WoG features
  • feasible enhancements (not altering game logic or totally no-harm)
  • small changes to the game logic (feasible but should be optional)
  • everything else
    That post can be edited once the features get implemented, while still on last page. If the topic grows to a next page, I can post a new overview with the latest situation, including also the new feature requests since the last overview post.
  1. Go through Item Implementation google list and add to Mantis any OH3 missing features not yet reported (I believe that list has only OH3 items + WoG artifacts, but those can be left for later)

  2. I could go through all Mantis feature requests, and rename Report subjects to “OH3 feature: …”; “WoG feature: …”; “Feature request: …”. Like this you - as coders - can filter by report type, then sort by name. Alternatively I could add appropriate tags to the reports (and create new Tag categories if needed). While going through the process, I can also raise or lower the priority of the reports depending on the case.

  3. I can also go through Mantis and clean it of reports which are not reproducible anymore.

Of course, any of the above would take time, which I don’t have a lot. At best I can do one a week (except #4 which will take longer because I usually try all combinations to make sure something is not reproducible anymore). So let me know your preference for me to prioritize. Of course, you can do it as well, especially as you run into them - but I’m thinking you’d rather want to focus on coding, which is the one thing I cannot do. :slight_smile:

  1. That list is very small - ~5 spells, WoG arts and campaigns. Everything else is already implemented.

  2. Probably better to use tags for this.
    One note on priorities\severity:
    severity: features are always features. Missing features should have some higher severity.

priority: I think that this is something that should be set by reporter. Crash that happens once in year (real-time :slight_smile: ) can have low priority but anything that can be annoying to player must have much higher priority.

  1. That would be great. At least for those reports that got no update in years.

This makes difference only for developers. Developers don’t need to have sticked master reports, we are capable of using filters. :slight_smile:

Yeah. I guess indeed missing OH3 features could be reclassified as bugs.

I think that wiki page would be more convenient here:

  • easier to edit by various people
  • automatically generated TOC
  • topic won’t grow to a next page :slight_smile:

By the way if you were to go through feature requests thread, I’d have one more request. In that thread there were a number of requests for various no-harm enhancements, some of them were implemented. It would be great if we have all of them documented in one place (eg. wiki.vcmi.eu/index.php?title=Engine_features ). There is little use from features that users don’t know about. :wink:

I’d use tags for that.