Thread Rating:
  • 2 Vote(s) - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Too many bug reports! Let's talk about it.
#1
There are a lot, and I mean a LOT of open (issue/bug report)s. And they keep popping up faster than they can be fixed. Can we do something about this?!

Really there's only a finite amount of issues in the game at a given time, and open issues are just catching up to the amount. New features do also introduce issues, though imaginably at a slower rate. The more people that are willing and able to volunteer their time to solve issues, the better. Furthermore, the easier it is for anyone to fix an issue, the better. Many issues are complicated, but some are one-liners. I'm not sure what could be done here, but that's what this thread is for.

Couple excerpts from imcoder:

leahthetech: "honestly a good portion of our issues are likely duplicates or no longer exist, but figuring out which ones are or not is :whelm:"
...
undead (aloe): "bait them in with the simple issues and then hit them with the 'actually the best way to do this is refactoring a whole system last touched in 1992'"
[on tagging issues with Good-First-Issue]
...
pali: "I open GitHub, see the number of open PRs and issues, have a mental breakdown, then close GitHub"
...
ME: "But yeah the constant increase in issues is scary"
ZeWaka: "is it though"
ZeWaka: "it just shows that people aren't paid to review and close issues"
...
Katz'n: "Maybe if it [amount of open issues] keeps going up it will overflow and the problem will be resolved"
...
tyrant:
new features = new bugs therefore:
    freeze features for a month, catch up on fixing bugs
    ???
    1156 issues --> 1243 issue
    cry

Jokey quotes, but they do point out a few issues with the current system. Some solvable, some probably not.

All this to ask, what can be done to fix all the bugs?

First step to fixing a bug is to find it.

As of writing this post, >70% of currently open issues (1243/1734) are issued by the Goonstation issuebot. And the amount of open issues has been steadily increasing since open source:
[Image: X0apRPm.png]
Because of this, I've thought it would be a fantastic idea to make it easier for players to be more descriptive when writing their bug reports. Issues with more information about how what the bug IS and how to reproduce it would be great, which starts with making the process of adding more info easier. After all, an unhelpful bug report means the bug behind it goes unresolved.

Currently, I'm trying to add category buttons to the UI, along with renaming the descriptions for severity tags. But I would like YOUR input into what would make it easier to add information to bug reports, and resolve issues overall.

Second step to fixing a bug is to reproduce it. Pretty good here in my opinion, build times can be slow but as long as you can recreate the bug and set breakpoints, you'll probably be able to figure it out unless it's a real headscratcher kind of issue. Might not even need to in the case of mapping issues.

Third step is to, well, fix it. Make code changes, build and test, repeat until bug no longer occurs. My issue with this stage is that building for a line of code change takes FOREVER (One minute-ish to build, another one or so with fast flags to load in, just to test changes, along with writing any code to expedite the process). Making DM build faster would probably be Really Hard, perhaps if possible code could be edited in real time. Definitely a hard change too. I don't see much changing here.

I would love to see more documentation in the codebase, personally. I often miss helper procs that I could have used for a PR that show up on the review because I don't know any way to determine their existence. More code commenting would be great, I'd love to make some PRs that just comment procs and files.

Last step is to publish the change as a PR. Spend a minute or two writing what you just fixed in the PR, link the appropriate issue, and submit. This step is also fine, though I imagine confusing for those starting out to wrestle with Git. But the starting instructions do a great job at explaining it step-by-step. No complaints here. (Secret final step being it gets merged)

Perhaps one day we will open github and the issues tab will be at 0....

Oh, and thank you for reading all that <3 ping me (@mynameisromayne) in discord if you reply so I can check it out

Quick edit: Please check out https://discord.com/channels/18224996089...2517177365, this is a channel dedicated to issue cleanup. If you have discussion more appropriate for the Discord than the forums, this is the place.
Reply
#2
I think there is sonething with the issuebot. I found a few bugs that i would like to close because they got fixed or turned out to not be a bug. If i make a github issue, i can close it myself.

Granted, for me it's just "i always forget to fill out the contributor form" and 100% a me-issue. But for non-coders this is completely out of the window. A way for non-coders to acess their bug reports would be an idea.

Beyond that, i have found many bug reports are feature suggestions. I mean this is not on the player, but often it's just "hey, i don't think this is logical" while the code is doing what it is supposed to be. I mean we should encourage players to maje bug reports, but i am not 100% sure how we should handle these kind of reports. Currently, they just stay open? On the other hand, maybe it's just me getting so used to a bug that i assume it's a feature, this has happened to me more kften than i like to admit.

In general, the biggest problem with the issues is... bookkeeping. Noone really bothers going over them. Many are outdated and they don't have usefull tags to sort. If i search for botany issues, i need to search for stuff like "plant", "tray", "saw" and others, instead of just hacking in the hydroponics label. On the other hand, coders are sometimes unable to label their PR's, we cannot expect it from non-coders.

In short, features make more fun to make than bug fixes, and just sifting through piles of issues instead of fixing bugs is even less fun. Noone likes to do it.
Reply
#3
Yeah, the issues really do just pile up. I attempted to kickstart a project working on closing as many ancient bug reports as possible (or marking them verified) but work on it fizzled out. https://discord.com/channels/18224996089...2517177365 if you're interested btw.

But yeah, it's a problem that grows. Every so often someone (e.g. Zewaka) goes through and eliminates a load of old bugs since they're simply not being looked at like at all, but that doesn't solve underlying problems of not having enough people to go around bug fixing. Hell, I'm guilty of this too. I'd much rather code in a new feature than spend half an hour parsing code i've never seen before in order to make sense of a logic error.

I've been trying to push out a lot of reworks and redos and QOL features, since it's really the backend that i'm more comfortable working with. Commenting code properly helps a lot and I agree that it should be done more, and to be honest most of the new stuff is done pretty well. The main culprit is stuff pre-2020 initial commit. My personal rule is "fix as you go" while making sure to atomise. Helps a bit but... doesn't catch everything of course.

As for more documentation, I actually put out a pr the other day adding more info about reviewing and labels, which should help a little bit in clearing up some confusion and not gatekeeping reviewing pr's to just devs (which many people seem to think is the case; it isn't). https://github.com/goonstation/goonstation/pull/15897 for those interested.

Category buttons would be absolutely fantastic. Maybe even a dropdown list. Because there are so many labels, the average bug reporter in game has like a 2% chance to guess the name of a keylabeler hook correctly. I approve one thousand percent.

I think have 0 github issues is outright impossible. But we can get close. Or at least make an attempt.
Reply
#4
(09-28-2023, 07:39 PM)Lord_earthfire Wrote: Beyond that, i have found many bug reports are feature suggestions.

evil idea (could actually be worth it): have a checkbox for 'is this a new feature' - and then just don't submit it if it's checked

could pipe it to a database or something eventually but this might help
Reply
#5
[Image: d9JaXja.png]
WE DOIN IT!!!
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)