Showing Posts For Esmerine.9465:
What would sticky get us? I don’t think it’s appropriate or useful here:
- This thread is not useful to all players; it applies only to a subset of players (however important the issue is to us).
- The information in this thread is relatively volatile.
- This thread is updated frequently, so users looking for it should have an easy time.
- This thread is the first thing that comes up with a search for “skritt” and is linked in the first result for “hatchery”.
- This thread has a response from ArenaNet, so there is a bright red icon to guide users.
We want recognition, but I don’t think that sticky is the right tool for the job.
Is it worth discussing, though, other ways for ArenaNet to recognize the impact of this bug and the patching process? Is there something ArenaNet could learn from the community here?
Judging by the level of communication and commitment from the team-members we’ve heard from, it sounds like they’ve got this under control. I, for one, am not yet willing to rescind all of my trust. Furthermore, I think the communication about and, to use somewhat of an industry buzzword, “ownership” of bugs like this in an organization like ArenaNet is impressive. It is a nice thing for a team-member to come out and communicate that a fix is being worked on—but it takes real guts to communicate the bad news (i.e., the delay due to merging with audio changes).
I think we will all be cheering in this thread when the fix is out.
I think such judgements are always personal, so let me say that I’m disappointed by the “ownership” of this bug. Another thread has been closed 12 days ago by the Head of the Global Community with this single line: “Well, Jeffrey has given his answer, I think this has run its course.”
That was the equivalent of a door rudely slammed in the face of customers who had (and still have, to this day) a problem. I don’t think that’s good service although some steps have gone in the right direction since that happened. Yet I can’t say, in all fairness, that this bug has been handled the way I would have liked, and I don’t believe that the different attitude in answers given by Anet members can be ascribed only to the different role of the members in the organisation: such inconsistencies can also be considered a bad signal and that’s how I interpreted the whole chain of events.
I just hope such opinion of mine is based on wrong conclusions so I’ll be more than happy to be proved wrong. But as of now I can’t say that I’m satisfied, and I think you won’t see me cheering here: the problem will be fixed and I’ll continue the personal story of my character just as I should have been able to do two weeks ago when I encountered this blocking bug.
I agree that such judgements are personal. Maybe I’m just jaded by my experience in the software industry, and what is poor service seems good to me by comparison—I’m certainly open to that possibility. I think that a lot of the reason I feel the way I do about this issue is that I know how difficult it is for organizations to change, and I know how easy it is to make a mistake when meaning well. A happy community is the carrot that encourages organizational changes to improve customer service. If no answer is good enough for us, why should ArenaNet try?
On many points, though, I think I agree with you. It’s not that I’m happy with the bug, how it’s been handled, &c.. However, while I think the frustration in this thread is entirely warranted, some of the complaints seem to be assuming a lot about software development in general, and ArenaNet’s organization in particular. I wanted to provide my perspective on this issue as another developer who has worked in a similar industry.
I too am not happy with how this bug has been handled (again, see my previous comment about version control), but I think ArenaNet has an opportunity here to grow. This thread is an example: someone pointed out that the previous thread’s closure removed a venting opportunity for a lot of frustration, and it seems ArenaNet has learned and is leaving this one open.
I too think that the inconsistent messaging was a bad signal. But I also accept that not all parts of a business can communicate constantly while still getting work done. You have to draw a line somewhere, and sometimes the community managers have to make a call like the previous thread’s closure. What we can hope for is that, with this thread’s creation, dialogue about the appropriateness of the aforementioned call will begin and both the community management and development teams can learn more about when such a decision is acceptable and useful. To me, ability to change and adapt is more important than getting the right answer the first time.
Keep in mind that the communication issues described are why many businesses only communicate to customers through their customer relations groups. I’d rather have a few inconsistencies if it means I get to hear from actual content creators now and then.
I apologize ahead of time for what I feel might be a more technical rant than some here might care for. I don’t know my audience very well.
TL;DR: ArenaNet has clearly communicated when they expect this to be released; give them a chance to earn or regain your trust.
IF this quest is bugged and obviously you can not fix it as we see…. just remove it or let us choose the other quest of the story line so we can have some progress in this game !!!Please i was trying for 3 hours to end it and im not ok now dat quest got me crazy … Ah….and dont tell us that you will get it fixed in the next patch … we want you to fix it NOW <3 plz ! ! !
This quest broke in first place because they tried to fix an insignificant bug in it, they would likely permanently break your whole story line if they rushed another fix in.
This is basically the mindset. It only takes one botched “emergency patch” to paralyze a development organization. Strangely, if there is one group that is sometimes immune to this effect, it’s us software engineers.
What can I say? We tend to be an optimistic bunch. We always want to fix the problem—especially when it’s a problem with our product. Many of us would gladly squeeze in another “emergency patch” to fix the previous patch, and some of the more well-meaning (and less clueful) among us will do this many times in succession. This is obviously not what ArenaNet is doing.
Meanwhile, the QA, release, &c teams (organization here can vary quite a bit) have just undergone Pavlovian conditioning: when we push quick fixes, bad things happen. “No more emergency fixes, everything must go through twelve levels of bureaucracy!” I doubt ArenaNet is doing this either, since their aggressive content schedule would not be sustainable with this development methodology.
Of course, the right answer is to work together and take a balanced approach—find out why testing didn’t catch the previous issue, see what you can do to catch this class of issue going forward while preserving as much of your ability to respond as is practical and beneficial. This often means process changes, and those are difficult and slow. Furthermore, the next few releases might be slow while intra-organization confidence recovers.
Judging by the level of communication and commitment from the team-members we’ve heard from, it sounds like they’ve got this under control. I, for one, am not yet willing to rescind all of my trust. Furthermore, I think the communication about and, to use somewhat of an industry buzzword, “ownership” of bugs like this in an organization like ArenaNet is impressive. It is a nice thing for a team-member to come out and communicate that a fix is being worked on—but it takes real guts to communicate the bad news (i.e., the delay due to merging with audio changes).
I think we will all be cheering in this thread when the fix is out.
It’s not a matter of priorities, it’s just bad timing, really. A general audio fix went in about 2 hours before the bug was reported here and I fixed it, and unfortunately, the audio fix left the story step incompatible with Live. In the upcoming update they’ll be adding the audio fix, so the fixed story step will also go in.
As a developer myself, it astounds me that when it was realized the fix for this quest was made on a branch of the code that included other changes that would not be pushed out as quickly, that the fix was not then also made on a branch of the code that could be pushed out prior to the audio fixes. This is just bad management.
Second: Fixing a significant live bug on top of what should be a feature branch is, frankly, a rookie mistake. It should have been made on the “Current live” branch for immediate test and release, then merged back into the trunk.
Third: Fine, forgot to fix the bug on the branch, it happens. It took four hours to track down and fix. Tracking it down is usually the hard part. Just reapply the known fix to the live branch. Absolute worst case it’s another four hours and would have gotten this fixed in live several weeks earlier than it is.
I’m going to throw my voice in and say “insufficient branch management.” However, I wouldn’t be so quick to call this a “rookie mistake”—many projects don’t lend themselves to this type of branching strategy. Furthermore, we can’t assume that the change was naïvely merged with a very complicated feature—it is entirely possible that the audio changes mentioned were expected to be pushed out much sooner than they did. Don’t forget, also, that more branching means more QA. This kind of organization is complicated, and we don’t have all of the information.
I think that there are branching and resource organization strategies that would greatly alleviate this kind of problem. It is, however, very difficult to change development habits across even a very small organization dealing with small, discrete projects and products. ArenaNet and Guild Wars are none of these. It could be better, but that isn’t the same as failure.
Hopefully, the teams involved can learn from this. That’s one of the fun parts of creating software.