Quote Originally Posted by Ocho View Post
Quote Originally Posted by Kendun View Post
An unreasoned response, laziness isn't the only factor here -- the search function is of limited use, as is visually scanning topic titles.
I actually mostly use google to search our forums, it works far better than the built in search functionality for most purposes. Google has put in a lot more time and effort in search than even the fanciest forum software.
Quote Originally Posted by Kendun View Post
That wasn't suggested. It was suggested that the list which certainly already exists be mirrored out to a web presence. I'm familiar with three different issue tracing systems, and they all provide such functionality. You can even mark things that could lead to an exploit as in-house display only. Of course such a system requires management to shift from a mindset of the secretive into a more transparent practice, and that's not always simple.
Quote Originally Posted by Narielia View Post
Speaking from a business point of view, if the advantages (time, money, resources etc) outweigh the disadvantages, and the the reward outweighs the risk, there will be no reason not to implement it.
These two quotes are both related, in that they address benefit/disadvantage. But there is a third member of this triumvirate that also needs to be considered, and that is cost. I'm not talking about cost in dollars, I'm talking about cost in what else we could do with the same development time. If something is more beneficial than problematic, that isn't an auto we should do this. Because we still have to consider cost to implement, and if we could do something with an even better benefit to disadvantage ratio in the same time frame.
Quote Originally Posted by Narielia View Post
I think the risk of using the info for malicious purposes, although there, can be negated. Why? This will not affect genuine players. I don't think for one second that a genuine player who has vested interests in this game will use this info maliciously. Second, having access to a bugtracker does not encourage exploitation. If someone wants to exploit, then they want to exploit. Regardless if they have access to the info or not. If they haven't earnt themselves a ban already, they will in due time. Maybe having this will help sort them out sooner? If anything, maybe it will give us a heads up where/what to look for if people are exploiting. It will remove all doubt as to whether or not someone is exploiting a known bug. Trion won't have to comb through logs. We'd just simply tell them the name, date, time + exploit. Lastly, there will always be people exploiting/botting. If someone wants to use the info for malicious purposes and earn themselves a ban, then that is their prerogative, is it not? The benefits of having this in my mind far outweigh the drawbacks of not having this. IE: The reward far outweighs the risk.
Sadly, my experience tells me that the easier it is for someone to learn about exploits the more likely they are to do it. If there is an easy exploit someone knows about, even if they are generally honest they are more likely to be tempted. It's not to their benefit to dangle potential exploits in front of everyone's faces.
Quote Originally Posted by Artewig View Post
I like the idea, but I see a way that this could hurt more than help. Given a list of bugs, you can get a general sense of how long a bug has been there. If Trion has not opted to fix a particular bug for a reason that may not be known to the community, there may be more pressure in the push to get that bug fixed. Instead of "I have this bug, can you fix it?", the forums will become "Why haven't you fixed this bug, when are you going to?" I think the latter is far more stressful to deal with. Most people do not understand all that goes into making this what it is and I think giving this information to players with minimal knowledge of how things work is definitely a risk for problems to arise. Overall, good thought, just not sure what the best way to implement it would be to insure that it is actually alleviating pressure and not creating more.
To delve further into the costs idea, aside from implementation this also incurs what I'd categorize as an ongoing development debt. Now all bug tracking has to take more time, because we know this will be publicly visible. We can't use internal shorthand, because that won't be readable. We have to make sure that we're not giving away confidently business information, stuff that our competitors could use. And we have to parse through user submitted bugs and translate them into something usable. That's the big point. User submitted bugs are rarely the kind of thing we use directly. Instead a QA person will take the time to get solid repro steps, identify whether this issue is limited by specific circumstances or part of a larger issue. And once the bug is created it has to be assigned out to the correct person, not something that would be possible for users to do. So those are a few of the development side concerns with an idea like this, and from a communication standpoint I'd have a whole different set of concerns. I actually see user submitted bugs from time to time, mostly when they rise to the point of becoming abusive to the folks reading them. It's distressingly common to see something profanity filled and full of calls for devs to commit suicide. Pro tip: this is a good way to stop playing RIFT. Nobody deserves that kind of abuse for any reason. So cool idea, but something that would take an enormous amount of work to make feasible with potentially difficult returns. But often these types of ideas help spark other ideas which are then used to spark other ideas until you get something finely polished and ready for prime time.
Jump to post...