Aren't bug reports and suggestions the same thing?

[xtfoster]

One is about making things work as intended, the other is about changing that intention.

Or to put it another way "One is about making things work as intended, the other is about changing things to work the way you want them too (as opposed to the way the designers intended them to.)"

 

[Zhein]

By reading the DD and patch notes.

So a country LEADER not having a picture is fine because they never promised that you won't have to play with not even a generic portrait, Or a country general no having a portrait, not even a generic one, is fine because they never promised it.

And people have to read every patchnote and DD to know what everything is supposed to do and not just use common sense like :

"Bouthan leader has a portrait but not spain it must be a bug" ?

 

[Louella]

A lot of games that have good bug reporting systems also have a very techliterate playerbase. Of the games I play, Dwarf Fortress, Starsector, Kerbal Space Program, are the ones which have good bug reporting systems, and which also have some very techliterate volunteers to do the crosslinking of duplicate entries and so on.
I've also played some other indie games where I've been able to talk directly with the programmer and describe a problem that later got fixed.

I've made some bug reports about things in HOI4 But, I am not very techliterate, despite doing a bit of modding things myself. I sometimes struggle to convey the problem I had encountered.
I do remember one thing that did eventually get fixed - the randomly generated female air aces , because Podcat was able to find the bit of code because I helped narrowed it down. It turned out to be a simple fix, but had been low priority, but I did manage to get it fixed eventually, and now everyone benefits in their own mods.

I think HOI4s playerbase is a bit too big for programmers to be able to deal directly with players, and I'm not sure there are enough people who are eloquent enough to write bug reports that convey the problem clearly enough for people to take action on.

 

[Simon_9732495]

I'm not sure there are enough people who are eloquent enough to write bug reports that convey the problem clearly enough for people to take action on.

I think the voting system in the bug report section can help a lot.
IF (big if) the Users see that bugs get fixed, if they have many upvotes, there will be a pretty good filter mechanism.

And I think we see it starting to work because high rated bugs get Dev answers.

So go ahead and Rate that bugs!

 

[jpd]

I think HOI4s playerbase is a bit too big for programmers to be able to deal directly with players, and I'm not sure there are enough people who are eloquent enough to write bug reports that convey the problem clearly enough for people to take action on.

Being a programmer/bug hunter myself, the thing that helps the most in hunting down bugs is this:

Is it reproducible? In other words, given a specific starting point (which, for games would be a save game file), can you specify a specific set of steps that will lead into triggering the problem? That will help immensely in getting bugs tracked down and ultimately fixed.

If it's in the form of "I was playing for hours and then this or that happened. I've no idea what I did and I haven't seen it since" then it becomes incredibly hard in pinning down what happened, what the cause was.

You don't need to have technical expertise in order to write good bug reports. But it helps if you have good, logical, reasoning skills. The steps to reproduce is key here.

 

[Áurum]

And how would an average person know what is WAD? It's not like DPS even documents all changes (at least somwhere available to general public).

This is the key. I have reported many bugs but I don't know if some of them are actually working as intended.

 

[CrasherZZ]

One of the application development methodologies that I have seen attempts to address the gray area between Bugs and Suggestions by classifying the work for developers as "Issues" and "Bugs". Issues are any change or enhancement to the application, and bugs are a narrow criteria that describes in detail how a specific issue is not working correctly according the "acceptance criteria" which defines the Issue. The Issue is sometimes called a "User Story".

The "User Stories" are ranked by the users in order of their preference. The reasons for their preference is not really of concern to the developers because they really only need to know what issues to work on first, second, third, and so on. Often though, the developers do modify the priority somewhat, if a particular change or enhancement would be so involved that it would pre-empt all other work that is required.

The key element in this approach is, though, that the list of issues presented to the users for voting must be clearly defined and presented so that there is no question, doubt, or confusion over what exactly was being proposed. The product manager needs to define them in a way that it is both practical for the developers and acceptable to the users. This is where a clear definition of the "intent" is really important. Then there must also be a QA process that verifies that the Acceptance Criteria has been met. If it fails QA or Beta, then it's a bug.

This is a cyclical process because new issues and bugs will always arise in any complex and changing application. Any application that is actually useful for many users tends to never cease becoming even more complex because requirements never cease to change. PS: This is a methodology for business not games but could apply to games?

 

[CraniumMuppet]

One of the application development methodologies that I have seen attempts to address the gray area between Bugs and Suggestions by classifying the work for developers as "Issues" and "Bugs". Issues are any change or enhancement to the application, and bugs are a narrow criteria that describes in detail how a specific issue is not working correctly according the "acceptance criteria" which defines the Issue. The Issue is sometimes called a "User Story".

The "User Stories" are ranked by the users in order of their preference. The reasons for their preference is not really of concern to the developers because they really only need to know what issues to work on first, second, third, and so on. Often though, the developers do modify the priority somewhat, if a particular change or enhancement would be so involved that it would pre-empt all other work that is required.

The key element in this approach is, though, that the list of issues presented to the users for voting must be clearly defined and presented so that there is no question, doubt, or confusion over what exactly was being proposed. The product manager needs to define them in a way that it is both practical for the developers and acceptable to the users. This is where a clear definition of the "intent" is really important. Then there must also be a QA process that verifies that the Acceptance Criteria has been met. If it fails QA or Beta, then it's a bug.

This is a cyclical process because new issues and bugs will always arise in any complex and changing application. Any application that is actually useful for many users tends to never cease becoming even more complex because requirements never cease to change. PS: This is a methodology for business not games but could apply to games?

That's a pretty common workflow in a lot of game development studios, or a version of it

 

[goodcigar]

This could tie in to Community Betas nicely. The Endless Legend/Space series developers practice a level of open development with their community.

 

[Ketchup & friends]

@HugsAndSnuggles
If you have doubts:
- always report as a bug when you thing something doesn't work right.
- if you have an idea how exactly to make it better, make a suggestion.

Or you could start a discussion in the main forum and make a suggestion based ton the discussion results.