Issue count will always inflate in its current state
- Oldman Robustin
- Joined: Tue May 13, 2014 2:18 pm
- Byond Username: ForcefulCJS
Issue count will always inflate in its current state
Until there is a change in how issues are dealt with.
I'm hearing rumblings about another freeze or some "issue for points" system because people are fretting about the issue count climbing past 1,000.
Everyone would benefit if maintainers changed how issues are dealt with. We could drop 500+ issues easy if we dropped:
1) Issues that could plausibly NOT be bugs (e.g. "Blobs aren't affected by flashes", "Kudzu gets disposaled when growing on chute")
2) Issues that were never reproduced and are >6 months old (e.g. "Ore Box contents spontaneously disappeared")
3) Issues that are not significant and have had a refactor that likely (>50% chance) fixed the issue (e.g. "You can emote in crit" from early 2016).
4) Any issues over 12 months old that has not specifically identified a method to guarantee a reproduction of the bug (e.g. "White shuttle vanished during end round transit"), make the cutoff 6 months unless it's a potentially critical issue.
5) ANY issue that is not plausibly worth addressing for the identified issue and therefore will not be addressed until there is some independent reason to change that code (removal, refactor, etc.). What I mean is stuff where the cost:benefit is clearly out of what and nobody will ever touch it with a 10ft pole because it is a tiny inconvenience affecting .0001% of rounds requiring a complete refactor of 3 major systems to resolve. If anyone ever gets around to fixing these it will be unintentionally, at which point they will still probably sit around because nobody will be sure it got fixed (e.g. "Singularity center object interacts oddly with other objects").
My view is that issue reporting reflects an "issue economy", right now our issue list is chock full of "Type 1 (false positive)" errors. Type 1 errors are extremely discouraging for people to try and address because it requires the "fixer" to go on multiple wild-goose chases and code digging only to find out that some refactor from Summer 2016 fixed it or they are never able to confirm its existence in the first place. Falling prey to these errors is extremely discouraging. On the other hand if we get too aggressive we start seeing more "Type 2 (false negative)" errors where a potentially real issue gets closed and continues to adversely effect gameplay. The catch is that the very nature of the reporting system provides a safeguard against serious Type 2 errors, if an issue continues to affect people, they will continue to report it.
It's not like it could possibly be more discouraging to have someone close your issue, forcing you to open a new one with more information - compared to opening the issue and then watching it collect dust for two years. "Freezes" and "Incentive Schemes" are heavy-handed solutions that don't solve the underlying problem and yet bring many costs of their own. Not saying the occasional freeze is a bad idea, but they are becoming more and more frequent as the issue count continues to climb.
Edit: The corollary to this post is "I could add 500 issues to the list if I wanted" - without higher standards on our issue list the limit to open issues is basically only limited by my free time and imagination in testing unintended interactions.
I'm hearing rumblings about another freeze or some "issue for points" system because people are fretting about the issue count climbing past 1,000.
Everyone would benefit if maintainers changed how issues are dealt with. We could drop 500+ issues easy if we dropped:
1) Issues that could plausibly NOT be bugs (e.g. "Blobs aren't affected by flashes", "Kudzu gets disposaled when growing on chute")
2) Issues that were never reproduced and are >6 months old (e.g. "Ore Box contents spontaneously disappeared")
3) Issues that are not significant and have had a refactor that likely (>50% chance) fixed the issue (e.g. "You can emote in crit" from early 2016).
4) Any issues over 12 months old that has not specifically identified a method to guarantee a reproduction of the bug (e.g. "White shuttle vanished during end round transit"), make the cutoff 6 months unless it's a potentially critical issue.
5) ANY issue that is not plausibly worth addressing for the identified issue and therefore will not be addressed until there is some independent reason to change that code (removal, refactor, etc.). What I mean is stuff where the cost:benefit is clearly out of what and nobody will ever touch it with a 10ft pole because it is a tiny inconvenience affecting .0001% of rounds requiring a complete refactor of 3 major systems to resolve. If anyone ever gets around to fixing these it will be unintentionally, at which point they will still probably sit around because nobody will be sure it got fixed (e.g. "Singularity center object interacts oddly with other objects").
My view is that issue reporting reflects an "issue economy", right now our issue list is chock full of "Type 1 (false positive)" errors. Type 1 errors are extremely discouraging for people to try and address because it requires the "fixer" to go on multiple wild-goose chases and code digging only to find out that some refactor from Summer 2016 fixed it or they are never able to confirm its existence in the first place. Falling prey to these errors is extremely discouraging. On the other hand if we get too aggressive we start seeing more "Type 2 (false negative)" errors where a potentially real issue gets closed and continues to adversely effect gameplay. The catch is that the very nature of the reporting system provides a safeguard against serious Type 2 errors, if an issue continues to affect people, they will continue to report it.
It's not like it could possibly be more discouraging to have someone close your issue, forcing you to open a new one with more information - compared to opening the issue and then watching it collect dust for two years. "Freezes" and "Incentive Schemes" are heavy-handed solutions that don't solve the underlying problem and yet bring many costs of their own. Not saying the occasional freeze is a bad idea, but they are becoming more and more frequent as the issue count continues to climb.
Edit: The corollary to this post is "I could add 500 issues to the list if I wanted" - without higher standards on our issue list the limit to open issues is basically only limited by my free time and imagination in testing unintended interactions.
- MrStonedOne
- Host
- Joined: Mon Apr 14, 2014 10:56 pm
- Byond Username: MrStonedOne
- Github Username: MrStonedOne
Re: Issue count will always inflate in its current state
>anchored itemOldman Robustin wrote:Until there is a change in how issues are dealt with.
I'm hearing rumblings about another freeze or some "issue for points" system because people are fretting about the issue count climbing past 1,000.
Everyone would benefit if maintainers changed how issues are dealt with. We could drop 500+ issues easy if we dropped:
1) Issues that could plausibly NOT be bugs (e.g. "Blobs aren't affected by flashes", "Kudzu gets disposaled when growing on chute")
>disposaled
>not a bug
come on man.
also, unexpected or inconsistent behavior is a bug. It is ether a bug user documentation or messaging or a bug in code.
And I think you are confusing the word issue with the word bug. nothing says only bugs can go in the issue tracker. This is why we have a bug label
Closing these would only add more bloat when they get recreated the next time somebody has the same bug. github search defaults to only show open issues2) Issues that were never reproduced and are >6 months old (e.g. "Ore Box contents spontaneously disappeared")
This is what the needs reproduction and can not reproduce tags are for.
3) Issues that are not significant and have had a refactor that likely (>50% chance) fixed the issue (e.g. "You can emote in crit" from early 2016).
This is what the needs reproduction and can not reproduce tags are for.
4) Any issues over 12 months old that has not specifically identified a method to guarantee a reproduction of the bug (e.g. "White shuttle vanished during end round transit"), make the cutoff 6 months unless it's a potentially critical issue.
after some time with a can not reproduce tag and no additional instructions, then we should close them.
Closing these would only add more bloat when they get recreated the next time somebody has the same bug. github search defaults to only show open issues
5) ANY issue that is not plausibly worth addressing for the identified issue and therefore will not be addressed until there is some independent reason to change that code (removal, refactor, etc.). What I mean is stuff where the cost:benefit is clearly out of what and nobody will ever touch it with a 10ft pole because it is a tiny inconvenience affecting .0001% of rounds requiring a complete refactor of 3 major systems to resolve. If anyone ever gets around to fixing these it will be unintentionally, at which point they will still probably sit around because nobody will be sure it got fixed (e.g. "Singularity center object interacts oddly with other objects").
If the issue still exists, even if it can't be fixed easily, the bug report for it has to stay open, other wise a new bug report will get added later down the line fragmenting the info and repeating the same shit.
This is what labels solve.
My view is that issue reporting reflects an "issue economy", right now our issue list is chock full of "Type 1 (false positive)" errors. Type 1 errors are extremely discouraging for people to try and address because it requires the "fixer" to go on multiple wild-goose chases and code digging only to find out that some refactor from Summer 2016 fixed it or they are never able to confirm its existence in the first place. Falling prey to these errors is extremely discouraging. On the other hand if we get too aggressive we start seeing more "Type 2 (false negative)" errors where a potentially real issue gets closed and continues to adversely effect gameplay. The catch is that the very nature of the reporting system provides a safeguard against serious Type 2 errors, if an issue continues to affect people, they will continue to report it.
You are attaching meaning to a state that should not have that meaning attached to it. Open vs Closed should not mean worth looking vs not worth looking at. Open vs closed should not mean confirmed fixable bug vs everything else.
- Cobby
- Code Maintainer
- Joined: Sat Apr 19, 2014 7:19 pm
- Byond Username: ExcessiveUseOfCobby
- Github Username: ExcessiveUseOfCobblestone
Re: Issue count will always inflate in its current state
How can you be affected when ever pr by your name is avoided like the plague regardless? They'd rather just feature freeze than tell you no
Voted best trap in /tg/ 2014-current
- CPTANT
- Joined: Mon May 04, 2015 1:31 pm
- Byond Username: CPTANT
Re: Issue count will always inflate in its current state
I went through the list last freeze and while there were some issues that could just be closed the vast majority were legit issues. I highly encourage you to do the same and see how many of these issues can actually be closed.
The fact is that we just have a massive amount of legacy shitcode.
The fact is that we just have a massive amount of legacy shitcode.
Timberpoes wrote: ↑Tue Feb 14, 2023 3:21 pm The rules exist to create the biggest possible chance of a cool shift of SS13. They don't exist to allow admins to create the most boring interpretation of SS13.
- Cyberboss
- Code Maintainer
- Joined: Mon Sep 26, 2016 7:58 pm
- Byond Username: Cyberboss
- Github Username: Cyberboss
- Location: Ontario, CA
- Contact:
Re: Issue count will always inflate in its current state
The issue tracker does grow every day, problem being nearly everything that goes on there is a legitimate issue and people don't have the willpower to fix them before they get stale and their reproduction becomes dubious. If we could get people to look at the front page of issues and just fix something more often than now, we might have a chance of fighting off the debt.
- Arianya
- In-Game Game Master
- Joined: Tue Nov 08, 2016 10:27 am
- Byond Username: Arianya
Re: Issue count will always inflate in its current state
Bugfixing isn't sexy and unlike a paid development team we can't force people to bug-clear except by feature freezing (and even then, some people just go on hiatus/work on their features in the background while better people bug fix). Thats the unfortunate reason the Issue count will always inflate.
Frequently playing as Aria Bollet on Bagil & Scary Terry
Source of avatar is here: https://i.imgur.com/hEkADo6.jpg
Source of avatar is here: https://i.imgur.com/hEkADo6.jpg
- kevinz000
- Joined: Fri Nov 14, 2014 8:41 am
- Byond Username: Kevinz000
- Github Username: kevinz000
- Location: Dorm Room 3
Re: Issue count will always inflate in its current state
how about you go fix some bugs, old man?
Local catgirl scratching post - Shezza
Usually seen as Skylar Lineman/Mekhi Anderson.
Commissions way too much art...
https://tgstation13.org/phpBB/viewtopic ... 7&p=239075 - IN GAME ADMINISTRATOR
Usually seen as Skylar Lineman/Mekhi Anderson.
Commissions way too much art...
https://tgstation13.org/phpBB/viewtopic ... 7&p=239075 - IN GAME ADMINISTRATOR
NSFW:
- Cobby
- Code Maintainer
- Joined: Sat Apr 19, 2014 7:19 pm
- Byond Username: ExcessiveUseOfCobby
- Github Username: ExcessiveUseOfCobblestone
Re: Issue count will always inflate in its current state
"easy fix" tag already existsCosmicScientist wrote:Maybe a rally where different issues are highlighted as "Hey, even you, the average player who knows nothing, have a chance at fixing this!" with possibly "For an entire month, we will have the coder credits dedicated to anyone who gets us out of this freeze."
That and animated rainbow beards for the same month. Or rainbow cat ears. Or rainbow lizard spines.
Voted best trap in /tg/ 2014-current
- Oldman Robustin
- Joined: Tue May 13, 2014 2:18 pm
- Byond Username: ForcefulCJS
Re: Issue count will always inflate in its current state
I've been through the issue list several times in the last few months.
My suggestions in the OP are basically 5 out of 6 of my reactions when I decide not to deal with an issue. #6 is "I don't have the competence to fix this", which obviously is a personal problem.
I have little formal training in code so maybe I'm just speaking heresies here but when I fix issues I do it for the same reason I open PR's... because I like improving the game. I know its not as sexy but if there is something detracting from my round I definitely will make an attempt to fix it.
I just opened a random page of issues and went down from the top:
1) No method to reproduce, happened during a DA round
2) Issues with an airlock. Some couldn't reproduce and others suggested it was a map issue.
3) Bug described with methods for reproduction. I couldn't reproduce under those conditions, I was a good boy and commented about this though.
4) Bug has no clear method of reproducing, bug may not even exist anymore, if it does exist it could come from any number of issues elsewhere in the code and thus this issue will never probably never be fully addressed until the issue becomes about a specific, replicable problem - best case is someone assumes they figured out the underlying cause specific to the OP based on virtually no details and closes the issue on that assumption.
5) Crew monitor issue LOL. I could make 1000 reports just on ways the crew monitor doesn't work properly. Also this couldn't be replicated - also this probably doesn't qualify as a bug.
6) Somewhat vague description of an issue, couldn't replicate based on what specifics were given.
7) I wouldn't even call it a bug/issue, people seem to think its fixed anyway, but it literally sounds like intended gameplay so who cares? (Mechs shred clothes on people inside lockers when they drill a locker apart)
8) Edge case #98439 related to mindswap. There are already plenty of issues describing this same problem in different contexts, a fix would require a big change to how minds are handled that would necessitate creating other unintuitive interactions... could be reasonably argued it's not a bug anyway because of assumption on how a magical mindchanging spell works.
9) Arguably not a bug/issue (aliens bounced a little when they leap into walls) comments claim this was fixed anyway.
And there goes my average visit to our issues page. No issues solved, no problems identified, no improvements to the game. Maybe we would achieve a more virtuous cycle if issues were limited to stuff that could be addressed so people won't feel that exploring the list past the first few pages isn't just a waste of time.
1) Some of it is test merge related or someone is already working on a fix, either way its pointless to address
2) Its related to a recent PR that someone else knows a LOT more about and could address it in a fraction of the time that you can, better off just yelling at them to fix it
Once you get past that "recent" section of the list it rapidly decays into what you describe, stale issues that have dubious reproduction. I'm saying if we were stricter about the issues we leave hanging around for several months/year, people would actually have a ripe ground for bugfixing.
My suggestions in the OP are basically 5 out of 6 of my reactions when I decide not to deal with an issue. #6 is "I don't have the competence to fix this", which obviously is a personal problem.
I have little formal training in code so maybe I'm just speaking heresies here but when I fix issues I do it for the same reason I open PR's... because I like improving the game. I know its not as sexy but if there is something detracting from my round I definitely will make an attempt to fix it.
I just opened a random page of issues and went down from the top:
1) No method to reproduce, happened during a DA round
2) Issues with an airlock. Some couldn't reproduce and others suggested it was a map issue.
3) Bug described with methods for reproduction. I couldn't reproduce under those conditions, I was a good boy and commented about this though.
4) Bug has no clear method of reproducing, bug may not even exist anymore, if it does exist it could come from any number of issues elsewhere in the code and thus this issue will never probably never be fully addressed until the issue becomes about a specific, replicable problem - best case is someone assumes they figured out the underlying cause specific to the OP based on virtually no details and closes the issue on that assumption.
5) Crew monitor issue LOL. I could make 1000 reports just on ways the crew monitor doesn't work properly. Also this couldn't be replicated - also this probably doesn't qualify as a bug.
6) Somewhat vague description of an issue, couldn't replicate based on what specifics were given.
7) I wouldn't even call it a bug/issue, people seem to think its fixed anyway, but it literally sounds like intended gameplay so who cares? (Mechs shred clothes on people inside lockers when they drill a locker apart)
8) Edge case #98439 related to mindswap. There are already plenty of issues describing this same problem in different contexts, a fix would require a big change to how minds are handled that would necessitate creating other unintuitive interactions... could be reasonably argued it's not a bug anyway because of assumption on how a magical mindchanging spell works.
9) Arguably not a bug/issue (aliens bounced a little when they leap into walls) comments claim this was fixed anyway.
And there goes my average visit to our issues page. No issues solved, no problems identified, no improvements to the game. Maybe we would achieve a more virtuous cycle if issues were limited to stuff that could be addressed so people won't feel that exploring the list past the first few pages isn't just a waste of time.
I agree but my OP was just another way to get to that place. The first few pages are more productive to visit but they suffer from 2 big flaws:Cyberboss wrote:The issue tracker does grow every day, problem being nearly everything that goes on there is a legitimate issue and people don't have the willpower to fix them before they get stale and their reproduction becomes dubious. If we could get people to look at the front page of issues and just fix something more often than now, we might have a chance of fighting off the debt.
1) Some of it is test merge related or someone is already working on a fix, either way its pointless to address
2) Its related to a recent PR that someone else knows a LOT more about and could address it in a fraction of the time that you can, better off just yelling at them to fix it
Once you get past that "recent" section of the list it rapidly decays into what you describe, stale issues that have dubious reproduction. I'm saying if we were stricter about the issues we leave hanging around for several months/year, people would actually have a ripe ground for bugfixing.
- Qbopper
- Joined: Fri Jul 10, 2015 6:34 pm
- Byond Username: Qbopper
- Github Username: Qbopper
- Location: Canada
Re: Issue count will always inflate in its current state
the problem isn't having non bugs/stuff that needs reproducing, like mso said, we have those tags for a reason
we just need someone to actually manage the tags and delete stale issues or something
you didn't need to write all this just to say what i said in 15 words
we just need someone to actually manage the tags and delete stale issues or something
you didn't need to write all this just to say what i said in 15 words
Limey wrote:its too late.
- MrStonedOne
- Host
- Joined: Mon Apr 14, 2014 10:56 pm
- Byond Username: MrStonedOne
- Github Username: MrStonedOne
Re: Issue count will always inflate in its current state
Robustins is a lawyer, its against bar ethics rules to make a point in less then 109 words.you didn't need to write all this just to say what i said in 15 words
He's legally required to write all those words
- iamgoofball
- Github User
- Joined: Fri Apr 18, 2014 5:50 pm
- Byond Username: Iamgoofball
- Github Username: Iamgoofball
Re: Issue count will always inflate in its current state
MrStonedOne wrote:Robustins is a lawyer, its against bar ethics rules to make a point in less then 109 words.you didn't need to write all this just to say what i said in 15 words
He's legally required to write all those words
- oranges
- Code Maintainer
- Joined: Tue Apr 15, 2014 9:16 pm
- Byond Username: Optimumtact
- Github Username: optimumtact
- Location: #CHATSHITGETBANGED
Re: Issue count will always inflate in its current state
I don't look at it because most issue reports are useless
- CPTANT
- Joined: Mon May 04, 2015 1:31 pm
- Byond Username: CPTANT
Re: Issue count will always inflate in its current state
Oldman Robustin wrote:I've been through the issue list several times in the last few months.
My suggestions in the OP are basically 5 out of 6 of my reactions when I decide not to deal with an issue. #6 is "I don't have the competence to fix this", which obviously is a personal problem.
I have little formal training in code so maybe I'm just speaking heresies here but when I fix issues I do it for the same reason I open PR's... because I like improving the game. I know its not as sexy but if there is something detracting from my round I definitely will make an attempt to fix it.
I just opened a random page of issues and went down from the top:
1) No method to reproduce, happened during a DA round
2) Issues with an airlock. Some couldn't reproduce and others suggested it was a map issue.
3) Bug described with methods for reproduction. I couldn't reproduce under those conditions, I was a good boy and commented about this though.
4) Bug has no clear method of reproducing, bug may not even exist anymore, if it does exist it could come from any number of issues elsewhere in the code and thus this issue will never probably never be fully addressed until the issue becomes about a specific, replicable problem - best case is someone assumes they figured out the underlying cause specific to the OP based on virtually no details and closes the issue on that assumption.
5) Crew monitor issue LOL. I could make 1000 reports just on ways the crew monitor doesn't work properly. Also this couldn't be replicated - also this probably doesn't qualify as a bug.
6) Somewhat vague description of an issue, couldn't replicate based on what specifics were given.
7) I wouldn't even call it a bug/issue, people seem to think its fixed anyway, but it literally sounds like intended gameplay so who cares? (Mechs shred clothes on people inside lockers when they drill a locker apart)
8) Edge case #98439 related to mindswap. There are already plenty of issues describing this same problem in different contexts, a fix would require a big change to how minds are handled that would necessitate creating other unintuitive interactions... could be reasonably argued it's not a bug anyway because of assumption on how a magical mindchanging spell works.
9) Arguably not a bug/issue (aliens bounced a little when they leap into walls) comments claim this was fixed anyway.
And there goes my average visit to our issues page. No issues solved, no problems identified, no improvements to the game. Maybe we would achieve a more virtuous cycle if issues were limited to stuff that could be addressed so people won't feel that exploring the list past the first few pages isn't just a waste of time.
I agree but my OP was just another way to get to that place. The first few pages are more productive to visit but they suffer from 2 big flaws:Cyberboss wrote:The issue tracker does grow every day, problem being nearly everything that goes on there is a legitimate issue and people don't have the willpower to fix them before they get stale and their reproduction becomes dubious. If we could get people to look at the front page of issues and just fix something more often than now, we might have a chance of fighting off the debt.
1) Some of it is test merge related or someone is already working on a fix, either way its pointless to address
2) Its related to a recent PR that someone else knows a LOT more about and could address it in a fraction of the time that you can, better off just yelling at them to fix it
Once you get past that "recent" section of the list it rapidly decays into what you describe, stale issues that have dubious reproduction. I'm saying if we were stricter about the issues we leave hanging around for several months/year, people would actually have a ripe ground for bugfixing.
2. Dude the airlock issue was again reported in februari. It has been an issue for ages and I've personally seen it multiple times
5. Yes crew monitors are incredibly bugged, this is indeed just one of its issues.
7. Light explosions shouldn't damage clothes any more and it is unintended behaviour
8. is a bug and hinders maintainability for datum antags. Mindswapped revs that switch to an implanted body should be deconverted.
9. can be closed.
I can't comment on those other issues since you have given me no way of identifying them.
Timberpoes wrote: ↑Tue Feb 14, 2023 3:21 pm The rules exist to create the biggest possible chance of a cool shift of SS13. They don't exist to allow admins to create the most boring interpretation of SS13.
- Not-Dorsidarf
- Joined: Fri Apr 18, 2014 4:14 pm
- Byond Username: Dorsidwarf
- Location: We're all going on an, admin holiday
Re: Issue count will always inflate in its current state
[quote="Qbopper"]
we just need someone to actually manage the tags and delete stale issues or something
/quote]
Any time you see one of these dead issues/test an old issue and are unable to reproduce, ping me and I'll close it.
we just need someone to actually manage the tags and delete stale issues or something
/quote]
Any time you see one of these dead issues/test an old issue and are unable to reproduce, ping me and I'll close it.
kieth4 wrote: infrequently shitting yourself is fine imo
There is a lot of very bizarre nonsense being talked on this forum. I shall now remain silent and logoff until my points are vindicated.
Player who complainted over being killed for looting cap office wrote: ↑Sun Jul 30, 2023 1:33 am Hey there, I'm Virescent, the super evil person who made the stupid appeal and didn't think it through enough. Just came here to say: screech, retards. Screech and writhe like the worms you are. Your pathetic little cries will keep echoing around for a while before quietting down. There is one great outcome from this: I rised up the blood pressure of some of you shitheads and lowered your lifespan. I'm honestly tempted to do this more often just to see you screech and writhe more, but that wouldn't be cool of me. So come on haters, show me some more of your high blood pressure please.
-
- Joined: Sun Oct 26, 2014 5:13 am
- Byond Username: Lzimann
- Github Username: lzimann
Re: Issue count will always inflate in its current state
People complain about "dead" issues, but only a few actually ping someone to come and close it and even fewer take their time to go and dig through the issues(and apparently you are doing but not telling anyone about what you can't reproduce/think it's no longer happening). You can't expect maintainers to read your mind.
- Oldman Robustin
- Joined: Tue May 13, 2014 2:18 pm
- Byond Username: ForcefulCJS
Re: Issue count will always inflate in its current state
A lot of it is "I think this ought to be closed but I can't prove that this vague description of a bug doesn't exist sooo".
MSO mentioned taking down the "Needs Reproduction" ones that have stuck around too long. That's a good start for toss out a lot of dead issues.
MSO mentioned taking down the "Needs Reproduction" ones that have stuck around too long. That's a good start for toss out a lot of dead issues.
- Qbopper
- Joined: Fri Jul 10, 2015 6:34 pm
- Byond Username: Qbopper
- Github Username: Qbopper
- Location: Canada
Re: Issue count will always inflate in its current state
oh I didn't want to do this because I thought all the people with perms to close the issues wouldn't/wouldn't want me to but if that's the case okNot-Dorsidarf wrote:Any time you see one of these dead issues/test an old issue and are unable to reproduce, ping me and I'll close it.Qbopper wrote: we just need someone to actually manage the tags and delete stale issues or something
sometimes it's hard to tell what is or isn't worthy of deletion because I don't have much of a background in ss13 coding yet though
Limey wrote:its too late.
- bandit
- Joined: Thu Apr 17, 2014 7:35 pm
- Byond Username: Bgobandit
Re: Issue count will always inflate in its current state
the other problem that people don't realize is all the easy bugs have been picked off in the last few rounds of freezes so the hundreds remaining (not counting the first few pages) are shit too entrenched for the average beginning coder. the farther back you go, the more arcane and fundamental things get
- oranges
- Code Maintainer
- Joined: Tue Apr 15, 2014 9:16 pm
- Byond Username: Optimumtact
- Github Username: optimumtact
- Location: #CHATSHITGETBANGED
Re: Issue count will always inflate in its current state
some do, some don't
Personally I don't like the issue tracker, so I get annoyed when people ping me in issues
Personally I don't like the issue tracker, so I get annoyed when people ping me in issues
- BeeSting12
- Joined: Sat Apr 16, 2016 1:11 am
- Byond Username: BeeSting12
- Github Username: BeeSting12
- Location: 'Murica
Re: Issue count will always inflate in its current state
why are you pinging me, im not your personal bug handlerCosmicScientist wrote:@optimumtactoranges wrote:some do, some don't
Personally I don't like the issue tracker, so I get annoyed when people ping me in issuesSpoiler:
-
- Joined: Fri Mar 13, 2015 10:26 pm
- Byond Username: KorPhaeron
Re: Issue count will always inflate in its current state
We're down a net ~45 issues the week after adding an arbitrary points system
- Cobby
- Code Maintainer
- Joined: Sat Apr 19, 2014 7:19 pm
- Byond Username: ExcessiveUseOfCobby
- Github Username: ExcessiveUseOfCobblestone
Re: Issue count will always inflate in its current state
Are GBPs really the answer to all our ailments?
Voted best trap in /tg/ 2014-current
- oranges
- Code Maintainer
- Joined: Tue Apr 15, 2014 9:16 pm
- Byond Username: Optimumtact
- Github Username: optimumtact
- Location: #CHATSHITGETBANGED
Re: Issue count will always inflate in its current state
Way to early to call that
-
- Joined: Fri May 02, 2014 3:01 am
- Byond Username: Incomptinence
Re: Issue count will always inflate in its current state
On minor issues that require a major overhaul to ever fix.
Wouldn't said overhaul introduce more issues?
I mean not that anyone bothers to do that.
Wouldn't said overhaul introduce more issues?
I mean not that anyone bothers to do that.
- Cyberboss
- Code Maintainer
- Joined: Mon Sep 26, 2016 7:58 pm
- Byond Username: Cyberboss
- Github Username: Cyberboss
- Location: Ontario, CA
- Contact:
Re: Issue count will always inflate in its current state
Hi thereIncomptinence wrote:On minor issues that require a major overhaul to ever fix.
Wouldn't said overhaul introduce more issues?
I mean not that anyone bothers to do that.
- oranges
- Code Maintainer
- Joined: Tue Apr 15, 2014 9:16 pm
- Byond Username: Optimumtact
- Github Username: optimumtact
- Location: #CHATSHITGETBANGED
Re: Issue count will always inflate in its current state
Cyber I think we need a wiki page or something that just lists how the count works
foreveryone here, it's based on the LABELS on your pr which can be applied by maintainers.
So you get credit for lots of stuff
foreveryone here, it's based on the LABELS on your pr which can be applied by maintainers.
So you get credit for lots of stuff
Who is online
Users browsing this forum: Google [Bot]