Stormforge-gg / Bugtracker-Mistblade

Official bugtracker for the mistblade realm.
12 stars 32 forks source link

I hate this bugtracker #234

Closed AHigi closed 2 years ago

AHigi commented 2 years ago

Description: There are no categories, it just looks like a wall of text, and cant really use it efficiently

Expected behaviour: https://bug.tauriwow.com/ 😉

query-wow commented 2 years ago

Agreed

H4Xx0R-PC commented 2 years ago

Labels are effectively Categories, it's just that only people with 'Triage' access to the Repo can assign Labels to issues. I don't know if there are ways around this or if there are other ways of handling this.

Some more Github Jannies could be useful.

https://docs.github.com/en/search-github/searching-on-github/searching-issues-and-pull-requests https://docs.github.com/en/issues/using-labels-and-milestones-to-track-work/managing-labels

Cold-Martijn commented 2 years ago

Issue confirmed. Very limited usability. Suggestion: make a new project (just like Legion, MoP and WotLK are projects atm) on bug.tauriwow.com for Stormforge if a new bugtracker is so badly desired. :)

stathis commented 2 years ago

cant really use it efficiently

Morelike "don't want to learn how to".

Personally I hate using random selfhosted tools for this. Github is comfortable and easy for everyone, has an easy to get into login system etc. So, while you're used to that crummy bugtracker, most people are not and have no interest in learning it.

TL;DR, just use tags/categories/labels.

query-wow commented 2 years ago

TL;DR, just use tags/categories/labels.

Oh wow, if only they didn't think of that before, and if you actually had someone dedicated and well versed to do that properly... such a brilliant conclusion

stathis commented 2 years ago

I understand it might be awkward for you guys to even use Markdown, judging from the previous reply. I assure you though that no sarcasm was involved in my response.

If it makes sense for your workflow, you guys can write a bridge for Github<->Flyspray or any application you prefer to use.

But I think the fact that Github is much more intuitive for most people is undeniable and thus you get more feedback from players.

I can conclude though with a "git gud" :-)

Aithne99 commented 2 years ago

Who tf are you in the first place.

And no, Markdown isn't required. The biggest problem I have with github's uncustomizable wall-of-issues and pretty rainbow labels is that the innate nestedness of WoW bugs isn't represented, users can't self-assign the labels (despite them usually at least knowing which class/zone/etc their bug is related to, on Tauri even some extremely low quality ramblings had a correct category set, and NO FLAG issues were usually the absolute bottom of the barrel and very easy to insta-close), and that it just tries WAY too hard to be a fucking mobile social media platform with the emojis, history events, "sleek and modern and rounded corners easy on the eyes BIG EMPTY SPACES" design, and that it's limited to like... 25 issues per page, and I CAN'T EVEN SEE ALL OF THEM IN A SINGLE PAGE without scrolling. Meaning, I get to look at a whole fuckiing lotta empty and not much useful info. Yeah, labels can have pretty colors, YAAAAAAAAY. I do like the dark theme, although I still wish there was substance in it.

Also, in the case of the Tauri flyspray, using Tauri logins conveys extra information since the bugtracker account is tied to the player's actual account, meaning we can pry the account for necessary information w/o having to rely on the user. Yeah, users need like two or three fewer braincells to start shitposting on the Github bugtracker thanks to a non-OAuth login, but not sure that's even an upside.

stathis commented 2 years ago

You can use many arguments (of which all are easily dismissable by the way), insults, capslock and whatnot to defend an archaic way of development and bug tracking, gloat and have wet dreams about implementing an oauth system, but that doesn't change anything -- it only shows your lack of experience on working with teams and emotional attachments towards the systems you're used to.

It's not about modern and sleek design, it's about staying current and becoming better - as we become better at managing, so do the projects we work on.

The fact is that more and more people and organizations now rely on tools like Github, enhanced with moderation and tagging bots resulting with unparalleled increase in productivity.

Just to parallelize: Sure you can even use Active Directory on Windows NT 3.51 for your office and it might work fine, love it, cherish it, doesn't mean that it's the best way to go.

Finally, the last thing you want is ever shipping a subpar product due to development or managerial stubbornness being more important than user input. But sure, you can continue using your much cherished archaic tools and pushing code with commits like "misc", "test fix", "some more misc", et cetera.

query-wow commented 2 years ago

Lmfao, yeah because 6 Devs with 2 expansions on their plate have a ton of time to configure bots, tags, labels. Get over it

stathis commented 2 years ago

Lmfao, yeah because 6 Devs with 2 expansions on their plate have a ton of time to configure bots, tags, labels. Get over it

Completely agree that it's too much work on their hands as the team is pretty small, especially if there's 2 teams having to get used to each others workflow, and a completely legitimate excuse to stay in tools they just know how to operate - for now.

I'm pretty sure though they'll find alot of people wanting to help (like, creating or setting up tagging, sorting bots is one idea, creating bug report templates, and many more ways) if they asked nicely! :-)

AHigi commented 2 years ago

Labels & tags aren't sufficient enough to quickly filter through the reports, since more than 80% of the reports aren't even marked.

This has nothing to do with markdown to be honest, I don't care about formatting until it doesn't look like someone threw up on it.

The main issue is when I open the issue list, all I get is a list. It would be easier if the reports would be categorized to spot issues that are up to my alley.

Example #1: image

Example #2: image

Since the reports are categorized, and involve an area specific to the game it is much easier to quickly fix them all in that zone I call that effective

stathis commented 2 years ago

Gee, I wonder how Adobe/Magento (small example) does it with so many branches, issues to track and much more complex filtering.

You do you I guess.

AHigi commented 2 years ago

I don't know who that is, neither do I care. Depends on the projects he manages, and the scope of each project. If he manages a couple of applications then each issue is related to that specific application, but since this a huge project with a lot of content and features, you can't imagine how much of a mess this kind of bug tracking looks like

stathis commented 2 years ago

A WoW server core, even with layering 6.0-like layering, is a very small project compared my example. I could go on and continue referencing projects either using vanilla Github issues or powered by bots or even letting users report on Github while the organization/team uses Jira via native integration.

So wrapping up, your reply just confirms the assumptions made in my third reply to this thread - you guys don't have much experience besides this project and are sadly not very into learning or adapting to new things. It's not bad or negative, just... someone would expect more.

AHigi commented 2 years ago

For this comment all I can take is that you simply can't fathom the scale of this project either. So by saying using a 3rd party platform or using other tools you mean this issue tracker could be useful.

We used flyspray because it suited our needs, our repositry isn't publicly hosted as a private project for obvious reasons. Hence that was our fastest way to keep track of issues indeed.

By not wanting to adapt to this mess (making tools, or taking time to analyze how this works more ) is not by choice, I personally can't waste my time on this. I can't adapt if I don't have time to adapt. Drawing conclusions like you (excuse me, "someone") would is a bit premature.

You lack the facts that made me voice this opinion, and others who got used to our bugtracker feel the same way.

I'm not saying, if someone would set up a managable system that I wouldn't use it. Sure I would. But as for many of us, we don't have the time to set up that kind of stuff.

You are mistaken by saying "we" are emotionally attached to xy bug tracker. It's not the case. But it instantly suited our needs, at that time, in those circumstances.

It took less time to set up and make it useful than how long this argument takes. You might think we're close minded, stuck in the past, lazy etc. I don't care. You have your opinion, but because you lack information you can't even fathom why I personally have this view.

Plus you didn't counter my initial argument at any point, you yourself admitted that tools could be used to make this more manageable. So all I can take from that you also think that it is a mess like this and could be more developer oriented, which was my point also.

In this state it is a hay stack. With proper tools I'm sure it could be very effective. But who has the time for that.

And now comes the part where you can argue that if we don't have time to manage our issues why event start a project.

And that's why you have just no clue how the develeopment of a competitive pvt server works in the first place.

How many categories of bugs you think a private server could have?

stathis commented 2 years ago

Scale of a WoW server? It's a statement based on relative experience anyway. I can mention projects with thousands of open issues with more developers working on them, getting fed info directly off of Github. That is besides the point.

Categories of bugs? Counting actual usable permutations it should be a hair under 10.000. With the auto increment being around ~40.000 on active tickets (not many opened issues for the supposed project size, surprisingly), maybe it's kinda cumbersome for users or it's not that complex.

Let's leave that out for now though.

What I get out of this issue goes way beyond development or bug tracking. It's if you want to create something that people enjoy, if you want to take suggestions -- having basic competence in communication and being open minded instead of attacking on first sight (like @Zerewa), dismissing people just for the "lulz", closing tickets with no explanation or with a god-wannabe attitude.

Being the best we can be can have great results and in effect improve your quality of life since I believe it would improve the monetary earnings out of this. You are, after all, professionals, aren't you?

But then again, you can stay defensive in your cirque du soleil of friends since you agree -- like nothing bad has ever happened because of a group of biased people agreed. :-)

Now, since we've gone out of topic and is maybe time to close this, I sincerely hope you guys see some logic behind my sayings. Your player base will thank you.

Aithne99 commented 2 years ago

I've never seen you contribute anything useful to any sort of bugtracker, or WoW server development, or anything. Hence, I doubt you have any sort of reason for preferring github bugtracker over our old Tauri one, which you likely don't even know, and if you do, I don't recognize your name, hence "who tf are you". People who know us, or follow our discord, or our commit logs know that if tickets were closed w/ no explanation it usually means "yeah k fixed", unless it's a low quality shitpost report, so I don't suppose you were someone who actively played on our previous server?

We also don't want to create an issuetracker that people enjoy - we want an issuetracker that WE DEVS can use. Player enjoyment is secondary, and having at least a minimal barrier to entry is even beneficial, since 40000 on autoincrement with our previous project still meant a LOT of garbage (the actual number of issues over all projects is just over 20k, since there is db duplication set up for them). And if you count "possible permutations" of labels (2^labelcount, yeah, Iknow), that reveals that you absolutely don't know what we use labels for. Since a lot of our issues are tied to the player-facing side, and, y'know, gameplay implementations, we previously labelled areas of gameplay, broken down by expansion pack, then zone, and also had master categories for all of them, because the way we assign dev resources is by zone and by expansion pack, and the way players can easily test our content is by zone and by expansion pack, and a lot of issues are isolated to these gameplay zones. We have about a hundred of these "tags" in a TREE STRUCTURE, and they are all mutually exclusive, and there was absolutely zero need for multi-tagging issues. The tree structure itself is useful, and having users be able to select the label is, too, and, again, Github has neither of these features, whereas flyspray did, and flyspray took WAY less time to set up than the host of github tools you're recommending right now. Enforcing an issue template is an artificial barrier to entry which also isn't automatic and requires man hours, which, again, we don't have many of. OAuth also isn't something we're attached to, it's something that we had to make do with but later recognized just how useful it is for information users are unwilling or unable to disclose on a public platform. I, for one, miss having that info too.

My personal preferences, for example, are DENSELY packed information (200 reports, customizable, in one page w/ about 40 of them visible without scrolling, compared to github's measly 25 per page and those taking up well over a standard horizontal fullhd screen) and easy oneclick search options (mostly for player character class related issues, which are the types of issues I am familiar with), neither of which this bugtracker has (no, having to look up filter syntax is not "easy one click search"), everything else is feature bloat in any sort of issue tracker, whether it was made in 2002 or 2020. It seems that Higi's preferences align with mine, which is why he, half-jokingly (since we're friends with the other team that maintains the project and created the bugtracker), half-seriously (since even some of our users prefer the old format) said that "this bugtracker is kinda oof", but it doesn't change that since he's the one working on fixing these issues, his personal preferences weigh way more than yours do.

stathis commented 2 years ago

40000 on autoincrement with our previous project still meant a LOT of garbage (the actual number of issues over all projects is just over 20k, since there is db duplication set up for them)

If your autoincrement goes up by 2 it means you have 2 masters which is lower than the minimum of 3 proposed by most DBAs. I hope you've safeguarded the engine for an unlikely but very possible split brain scenario. Of course you're backing up, but this could be better. /offtopic

We also don't want to create an issuetracker that people enjoy - we want an issuetracker that WE DEVS can use. Player enjoyment is secondary

That's really really wrong. The issue tracker should be easy for users to add info to AND devs to grab them and do work. It does not serve only one side.

It cannot be understated how important UI/UX is for a system that's supposed to help users. If the bugtracker is only for devs, better use Asana, am I right? :-)

We have about a hundred of these "tags" in a TREE STRUCTURE, and they are all mutually exclusive, and there was absolutely zero need for multi-tagging issues. The tree structure itself is useful, and having users be able to select the label is, too, and, again, Github has neither of these features.

Use multiple tags/labels and filter by them. Tree structure is obsolete for tracking these. Again, I understand what you're accustomed to, but I believe that if you get used to this you won't go back. Github does support filtering by multiple. You can even try Jira and have it import issues. Both us players and you devs win.


Have we reached a conclusion yet?

Aithne99 commented 2 years ago

Yeah, you've clearly never played, never contributed, never talked a single word w/ Higi previously, don't understand what he means by ;), and don't understand that the game itself has a literal, naturally occurring tree structure. We have, for example, bug reports related to Europe, within which are bug reports related to France, Germany, and Spain, and we assign dev power based on "countries", and trust users to categorize the reports as AUSTRIA if it's about sth like "Benches in Vienna park are bent and old and need replacing", or EUROPE if it's about "Most European capital cities are spelled wrong on the ingame map". And users can actually assign labels, so the two devs assigned to Europe (because they are familiar with those pieces of ingame content because they recently wrote it) can find those tickets. (Country names do not directly correspond to ingame zones, but are very closely analogous). Having this categorization is a user QoL feature AND a dev QoL feature, since users do also happen to have directed interests in the same tree structure, but it's still more on the dev QoL side. And dev QoL >>>> user QoL, always, especially since we have OTHER, very much user-focused platforms (99% of the users who get here are here through those user-focused platforms after specific instructions on how & what to test or report), but github does not add nearly as much user QoL as it takes away dev QoL compared to our previous solution.

stathis commented 2 years ago

I'm sorry, your reply isn't very structured so I can't really understand what you mean.

Anyway. Developers are supposed to fix problems that users have. If users can't easily report problems that break their ingame QoL or just can't be bothered because of an unattractive system, what's the point? What is this, a large fun pet project that's coded by you and only for you? :-)

I know, you might find the "unattractive" part laughable, and trust me, it can be. But it's real.

Aithne99 commented 2 years ago

Yeah it's hard to understand if you're not familiar with the project you're talking about even as a player, but some of our players specifically would love the bench analogy. Stormforge.gg is where you can register, launch is on the 7th, until then we're running a beta realm :) Feel free to test it out. Discord.gg/stormforge is our discord, and you'll find that the problems most users have don't even concern the developers, but users sometimes cannot differentiate between "things they don't know" and bugs, which is why we have a sizable customer support team over there.

stathis commented 2 years ago

It's hard to understand if the reply is not structured -- I hope your customer support team communicates better! :-)

You can head out to https://github.com/features/issues to witness an actual tool at work.

query-wow commented 2 years ago

I think you didn't read the part where they actually use the user data that users don't disclose here and they have access to when they use their own bugtracker which btw is vital to pin point several issues because they can literally clone your character, see your character state, auras, etc etc, which is harder to make here unless you want to advertise to the world your account name here, it actually makes the whole process much much harder. So you can take your theory elsewhere

stathis commented 2 years ago

Well, what we take from this conversation then is that devs don't care about the users that kinda feed them, kicking back in every possible way like a newborn child.

Dully noted and sorry for the fuss.

query-wow commented 2 years ago

i'm not a dev btw, i just play here for a long ass time and i know how stuff works

Aithne99 commented 2 years ago

Don't mind that the users who commented on this github report have been the most valuable contributors in the past, having learned the three button presses it takes to open an issue on a flyspray based bugtracker, and they seem to have the stance that it is difficult for them to be as valuable as contributors as it was in the past due to lower QoL.

I think I know who you are now, though. Bye :)