Arjen Lentz
Assigned
Reported
Comments
As an experienced programmer and project manager, I feel a tad frustrated by the frequent "is this still an issue in this new version" questions. It essentially means that all bugs become invalidated when a new version is released, and everybody has to reconfirm the previously reported bugs.
That seems like a very inefficient way of bug report handling, and also seriously discourages user feedback - the latter is of course vital for the continued success of a software product.
Here is my suggestion:
Basically, unless something has been changed in related code, a bug should remain valid.
Since you'll have detailed change tracking internally, you'll know when this is not the case, and then it's indeed good to ask users to re-verify.
Dear Mods - do you have any reason to believe that the bug may no longer exist in the current version?
It's still valid in 1.6.2.
I'm not fussed on preference, as you can specify a direct IPv6 address rather than using a domain name. Even if IPv6 has bugs, having it enabled then allows people to try it, see if it works for them, and report bugs. That's a good thing.
For me, IPv6 worked fine in 1.5.2, and doesn't work at all in 1.6.1
The below is from the dev console of the client, it appears to not deal with the IPv6 numeric address at all. The server list in 1.6.1 reports "Communication error" for a server specified as an IPv6 address (IP, not name).
I regard that as a regression: something that previously worked, doesn't now.
Client> 2013-07-03 14:06:40 [CLIENT] [INFO] Connecting to xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx, 25565
Client> java.net.SocketException: Protocol family unavailable
Client> at java.net.PlainSocketImpl.socketConnect(Native Method)
Client> at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339)
Client> at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200)
Client> at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182)
Client> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391)
Client> at java.net.Socket.connect(Socket.java:579)
Client> at java.net.Socket.connect(Socket.java:528)
Client> at java.net.Socket.<init>(Socket.java:425)
Client> at java.net.Socket.<init>(Socket.java:241)
Client> at bcn.<init>(SourceFile:70)
Client> at bcq.run(SourceFile:42)
Ok, I understand (didn't know before) about the mods not being Mojang employees.
Discouraging user feedback is throwing out the baby with the bathwater.
If people just want to know how to do something or want to have a whinge, then providing appropriate public facilities for that will discourage other tools (such as JIRA) from getting used for that purpose - because indeed JIRA is definitely a bit higher end.
However, people who are serious about providing real bug reports will probably have sufficient experience to deal with the JIRA interface, as it's not that different from Bugzilla, Launchpad and other systems.
In terms of volume, I have experience with a large number of companies and products that have public bugtrackers - the reason for that is that those are Open Source projects. So you can think about OpenOffice/LibreOffice, Mozilla Firefox and Thunderbird, and so on. Various Linux distributions (Ubuntu, for example).
All very substantial and sure many bugreports are not "real", and it's fantastic when people from the community help, that's in fact how all these products make the system work. The people help out because they realise it's critical for the quality of the product, so by helping others and the project they help themselves as well. It's a complete win.
I'm not petitioning Mojang to make Minecraft open source, that's not the issue here and it's entirely their choice. Even for closed source, some form of the "raw" changelog (just the commit msgs) could be made available for the moderators, that would provide a very good guide. A bugfix tends to reference the bug#s it fixes.
So in summary, I don't think the fundamental problem is volume, it's process. Others do more volume so it's definitely possible. The challenge is to figure out how to do it in a non-opensource environment. I think it can be done.
I'm happy to provide bugreports, and some of mine have been pretty detailed - should give the developers a good angle on where to look. But I do feel the need to then be taken seriously, and not have to re-tag the same issue or see it be closed without resolution.
I reckon that experienced moderators can distinguish between a whinge and a serious bugreport. That filter is a human one, and unavoidable.
Also, Mojang devs themselves can do their thing here so it doesn't have to be all just moderators.