SUMMARY On 2019-07-12, I set ticket #344679 to status NEEDSINFO, with resolution WAITINGFORINFO. On 2019-08-01, an account named "Bug Janitor Service" added comment #13, asking the "bug submitter" to provide more information. On 2019-08-16, no one had provided the requested information, and the same "Bug Janitor Service" marked the bug as resolved, with resolution WORKSFORME, as indicated in comment #14. I've witnessed the same phenomenon in tickets #313424 and #379026, in a short period of time, so I know this is closer to a general rule than an isolated case. In short, it seems that every time a ticket stays with status NEEDSINFO for one month, "Bug Janitor Service" will mark it as resolved. STEPS TO REPRODUCE 1. File a ticket 2. Set it to NEEDSINFO WAITINGFORINFO 3. Wait for 1 month OBSERVED RESULT I haven't actually tested that myself, but I would guess "Bug Janitor Service" would mark the ticket as resolved 1 months after step 2 is completed. EXPECTED RESULT The ticket should still be marked as waiting for information, not be marked resolved, and not be set to resolution WORKSFORME, unless that applies and/or the issue was solved. ----- "Bug Janitor Service" appears to be a bot made with good intentions. It may be a little hurried, but I find it useful to remind reporters to provide requested information. I am not saying this is really a bug in bugs.kde.org, but it needs to be determined who is operating that bot, and how it can be operated properly. "Bug Janitor Service" advertises email address bug-janitor@kde.org, which I am setting as CC of this ticket. Hopefully, that will bring this person to this discussion.
You described the behavior of the bot but you didn't say why you think it's wrong.
Well, this is a complaint about the state names, which needs to go to the kde-community@kde.org mailing list. Musing this in a bug report seems entirely pointless. The current behavior is the result of earlier discussion and consensus on aforementioned mailing list, so further discussion should go there I would think.
Yep, what you're describing is exactly the way it's supposed to work: if information is requested but not provided in a month, the bug gets closed. We implemented this system to alleviate demands on human bug triagers and to provide clarity and finality for the thousands of bugs that had NEEDSINFO WAITINGFORINFO as the status. If you think this is a problem, please bring it up on the kde-community@kde.org mailing list, as Harals indicated.
(In reply to Harald Sitter from comment #2) > Well, this is a complaint about the state names, which needs to go to the > kde-community@kde.org mailing list. Musing this in a bug report seems > entirely pointless. This is not a complaint about state names, but a report of the defect described. If you think there is an underlying bug with state names or whatever, you are free to say so here or on a topical mailing list. > The current behavior is the result of earlier discussion > and consensus on aforementioned mailing list, so further discussion should > go there I would think. Issue trackers are the canonical place to discuss issues. If there was related discussion on that mailing list though, it would be useful to reference it here (and perhaps cross-reference with a mail to the list pointing here).
(In reply to Nate Graham from comment #3) > Yep, what you're describing is exactly the way it's supposed to work: if > information is requested but not provided in a month, the bug gets closed. As described in Summary and in the Description, the status gets set to RESOLVED and the resolution to WORKSFORME, which is hopefully not how it's supposed to work. > We implemented this system to alleviate demands on human bug triagers and to > provide clarity and finality for the thousands of bugs that had NEEDSINFO > WAITINGFORINFO as the status. Who are you ("we")? How would this system "alleviate demands" on bug triagers? And what do you mean by "providing finality"? > If you think this is a problem, please bring it up on the > kde-community@kde.org mailing list, as Harals indicated. I certainly think that's a problem; I wouldn't be reporting it otherwise. Please avoid marking tickets as resolved until the problem reported was solved.
I'm sorry this isn't going how you expect. But it's the way the system is designed to work: if the requested information is not provided, the bug eventually gets closed as RESOLVED WORKSFORME. This is merely a short way of saying "the respondent never provided the requested information proving that it's an actionable issue, so we are closing the bug because we do not keep un-actionable bugs open." That's the way the system is designed to work. I don't see any actual problem here.
(In reply to Nate Graham from comment #6) > I'm sorry this isn't going how you expect. But it's the way the system is > designed to work: if the requested information is not provided, the bug > eventually gets closed as RESOLVED WORKSFORME. That's not how it was designed to work. Your bot makes things "work" that way, but the system itself doesn't "work" that way, and it's not designed for such a bot. If you don't want to disclose who's behind the bot, at least have it disabled. What could possibly be done instead is to propose that KDE, as an organization, adapts bugs.kde.org to reach your objectives in a proper and integrated way. > This is merely a short way of > saying "the respondent never provided the requested information proving that > it's an actionable issue, so we are closing the bug because we do not keep > un-actionable bugs open." I don't know what you mean by "the respondent", but in any case that is not at all all it says. As documentation shows, setting to RESOLVED WORKSFORME says all of the following: 1. That the issue was resolved. 2. That all attempts at reproducing the problem failed. 3. That the contributor who set resolution to WORKSFORME failed to reproduce. 4. That the contributor who set resolution to WORKSFORME read "the code" and concluded it should not cause the reported behavior. 5. That the ticket is a bug report (implied by the above). > That's the way the system is designed to work. I don't see any actual > problem here. In that case, thanks for resetting resolution (it seems I cannot do that trivially). Resolution INTENTIONAL only applies to actual problems. If you do not see the problem reported by a ticket, you can set it to NEEDSINFO, *not* to INTENTIONAL.
I think I see the problem. You forgot to read https://community.kde.org/Get_Involved/Issue_Reporting#Understand_what_the_resolution_statuses_mean. :) I think I understand that this doesn't work the way you think it should work. But it works the way *we* think it should work, "we" being KDE's bug triagers, system administrators, and software developers. You are still welcome to make an argument for why the status quo is wrong or bad or harmful or doesn't work. But continuously re-stating descriptions of it in various forms is not likely to change anyone's mind.
(In reply to Nate Graham from comment #8) > I think I see the problem. You forgot to read > https://community.kde.org/Get_Involved/ > Issue_Reporting#Understand_what_the_resolution_statuses_mean. :) Hah. I have been contributing to KDE for more than a decade. Even that site didn't exist when I started reporting issues. In any case, putting your creative interpretations on that page does not make them reality nor even majority interpretations. Your tracker etiquette section is generally helpful, but: 1. Section "Don't confirm your own issue" is unclear. I think you may have a valid concern here, but the proper way to address it is to file a ticket against bugs.kde.org. 2. Some sections have nothing, nothing clear or little to do with etiquette ("Avoid arguments", "Have a thick skin", "Don't confirm your own issue", "Submit patches using Phabricator, not the issue tracker", "Understand what the resolution statuses mean"). 3. It seems rather childish at times (in particular section "Avoid arguments). I'm not sure young people will read such long pages, but I would recommend to put essential stuff before subjective parts, so people don't stop reading before they get to important stuff. 4. It could be a little briefer (I fail to see value in sections "Avoid arguments" and "Have a thick skin", at least as they currently stand). 5. Some of the objectives your section tries to achieve would be better accomplished by improving bugs.kde.org. This is particularly true for parts which contradict current bugs.kde.org, like section "Understand what the resolution statuses mean". Please file tickets if you think that would help instead. And by the way, language like "your own Bugzilla ticket" should be avoided - we don't want reporters to think they have exclusive ownership over tickets they file (or anything else they start in KDE). My general recommendation to fix the structure would be to split this page in 2. You could have a new page which only covers issue creation steps, which would make it more comfortable to add top-level sections, as the top level wouldn't be some awkward mixture anymore, and it wouldn't be so tempting to abuse the etiquette section. Or, make all step sections subsections. > I think I understand that this doesn't work the way you think it should > work. But it works the way *we* think it should work, "we" being KDE's bug > triagers, system administrators, and software developers. I know you are trying to help KDE, and I appreciate your work in general. But if you want to help with this bug, stop ignoring what others write, and rather than keep arguing (which, according to your own account, "almost always gets nowhere"), start by answering questions. At this point, no one has taken responsibility for Bug Janitor Service (even you haven't done so explicitly). Assuming you are the (main) person who implemented, please do not take this report as an accusation. As I think I wrote initially, I understand it tries to help with a problem. It's just the solution chosen which is wrong. Please simply take this as an opportunity to discuss how Bug Janitor Service could achieve its goal properly. > You are still welcome to make an argument for why the status quo is wrong or > bad or harmful or doesn't work. But continuously re-stating descriptions of > it in various forms is not likely to change anyone's mind. I am happy to let you keep your opinion. All I'm asking you (if you're not responsible for Bug Janitor Service) is to fix this ticket's status; you broke it, you get to fix it. If you can't do it yourself, at least have the decency of finding someone who can, file a replacement ticket - or just fix the bug.