Jump to content
TrinityCore

Can we please adopt best practices for how we manage tickets?


nubqt
 Share

Recommended Posts

Tickets reporting incidents in a granular manner are being closed in favor of keeping tickets that describe large, vague, and obscure issues. For instance, I reported that Skittering Spiderlings in The Hinterlands are attackable rather than lootable only to get that ticket closed in favor of keeping a ticket titled Cataclysm Zones - Quests + Phasing. So now, rather than tackling the spiderling issue, which is an easy fix, we can't apply the solution until the Cataclysm ticket is solved entirely. That is bad policy. The process of Incident Management has been developed, polished, and heavily tested for more than thirty years and separates incidents from problems. The way that @DoctorKraft managed this ticket is the right way to do so: a User-Acceptance Tester (UAT) reported an issue and @DoctorKraft then created a separate ticket that explains the technical problems causing that incident for developers to solve. It allows specialization by having testers reporting issues while developers focus on building code that testers can then test.

Furthermore, putting everything into a single huge ticket describing large, vague, and obscure issues goes against the paradigm of divide-and-conquer in software development. That paradigm establishes that the best way to solve a big issue (such as 'Westfall is not scripted') is by breaking the problem into many small problems (such as Quests 'Hot On the Trail: The Riverpaw Clan' and 'Hot On the Trail: Murlocs' are available before completing quest 'Murder Was They Case That They Gave Me' and Two-Shoed Lou is not phased in after getting quest Meet Two-Shoed Lou). That paradigm allows developers and scripters to fix tiny problems that incrementally solve the big issue, rather than having to wait for the entire big issue to be solved in order to apply the fix.

Moreover, this policy discourages UAT testers from testing the core. For example, if I wouldn't have tested the Hero's Call Board in Ironforge (which is considered a Cataclysm zone) we wouldn't have discovered that there is a feature missing in the core. Same thing when I tested Rune of Fire in Dun Morough (which is also considered a Cataclysm zone) which allowed us to find that the spell Burn Constriction Totem does not support the `conditions`.`SourceTypeOrReferenceId` for CONDITION_SOURCE_TYPE_SPELL which is also a core issue. But what incentives do I have now to continue to do UAT if the time and effort I spend in such testing is worthless since my reports will get closed on behalf of tickets that describe large, vague, and obscure issues?

I suspect this is one of the factors why Ohloh reports a -31% decline in contributors to this project in the last twelve months. If you discourage contributors like UAT testers to participate, what do you expect? I don't think that's what we want as a community.

Fortunately, the incident management process in software development has been well documented and developed in the past thirty years. There's no need to reinvent the wheel.

But if we want to make this project flourish and more successful that what it already is, we should start adopting best practices and encouraging people--particularly UAT testers--to contribute rather than disincentivize them.

Edited by nubqt
  • Upvote 1
Link to comment
Share on other sites

You are comparing ITIL process to an open public project? Also, I am a bit confused when you say "tickets". Are you referring to forum posts and/or open requests on git?

I read your wall of rant and I'm at a complete lost on what your requesting within Help and Support. This isn't a company, and some the of the practices (regardless of ITIL) don't need to be adapted, hence contribution factor and NOT a "business".

  • Upvote 1
Link to comment
Share on other sites

I read Killyana closing 20917 in favor of 15182 as just what it "says", its assigned and accepted to Killyana in an existing effort. Rushor sort of makes me feel, in brief, that the right person is working on it. I assume when 15182 is closed, a new ticket like 20917, created thereafter, would be accepted as there would be no assigned an accepted effort that.

That said 20917 being closed without comment, canned or otherwise, is rough/confusing. I think Issues like 20917 would serve these new issues better with a commentary a kin to "issues closed related to this are done so to ... [explaination continues]"

It is extremely "bad for business" to create thousands of tickets for wip quests, npcs, items; the raw count makes the product look overly issue ridden; when it's actually a project that is wip.

Link to comment
Share on other sites

WTF?!!

Did you read what I just posted? This is NOT a business!!
@Ibeatdungeon, Ask the dev or OP why it was closed, they don't have to give an answer. This is a contributed project. It's not even in the guidelines for devs to say why they closed an issue.

Now... with that said.. yes I agree: some explanation would be nice, however, it's entirely up to the devs to adapt a "polite" mannerism to issues while closing and/or commenting.

  • Upvote 1
Link to comment
Share on other sites

14 hours ago, Ibeatdungeon said:

WTF indeed, that's a pretty narrow reading of "bad for business" and pretty explosive reaction to a common idiom.

Meh.. Not really explosive. Just defending the fact that people consistently "demand" things from the community and devs. Sometimes they offer money and when they don't get an answer they are the ones that explode.

If you knew me, I'm a very very laid back guy ^_^

  • Upvote 2
Link to comment
Share on other sites

@nubqt has a good point, although it is true that this is not a business, if we should consider doing the job easier. As it is often requested that large RPs be split into several smaller ones, there should be the possibility of splitting long lists of problems.

Some of the advantages that I personally see:
 
-Would allow those who know how to develop something specific to do so without depending on fixing a problem that they do not know how.
-We can get fixes more often.
- See more easily how problems are solved in each case, learning will be more easier.

Link to comment
Share on other sites

57 minutes ago, HannibalRoG said:

@nubqt has a good point, although it is true that this is not a business, if we should consider doing the job easier. As it is often requested that large RPs be split into several smaller ones, there should be the possibility of splitting long lists of problems.

Some of the advantages that I personally see:
 
-Would allow those who know how to develop something specific to do so without depending on fixing a problem that they do not know how.
-We can get fixes more often.
- See more easily how problems are solved in each case, learning will be more easier.

For the PRs it's said to allow faster reviews, no one want to review 10.000 rows PR.

For the bugs, if the whole zone is un-scripted, there is no point of open 100 tickets for it.

Link to comment
Share on other sites

 Share

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...