Package: qa.debian.org Severity: normal X-Debbugs-Cc: debbug.qa.debian....@sideload.33mail.com Control: affects -1 +www.debian.org
There are essentially no documented policies or procedures for bug report archival. The only disclosure on the website is here: https://www.debian.org/Bugs/server-control#unarchive It’s so minimal I will just copy it here: > archive bugnumber > > Archives a bug that had been archived at some point in the past but > is currently not archived if the bug fulfills the requirements for > archival, ignoring time. > > unarchive bugnumber > > Unarchives a bug that was previously archived. Unarchival should > generally be coupled with reopen and found/fixed as > appropriate. Bugs that have been unarchived can be archived using > archive assuming the non-time based archival requirements are > met. You should not be using unarchive to make trivial changes to > archived bugs, such as changing the submitter; its primary purpose > is to allow for the reopening of bugs which have been archived > without the intervention of BTS administrators. That’s it. There is no further guidance in the www.debian.org/Bugs/* tree. It seems to say artificial archival can only be requested on bugs that were previously archived. Yet there are bugs that have been archived just 1 month after opening. This indicates undisclosed / non-transparent procedures are in play. Then it says unarchival should only be requested on naturally archived bugs (due to aging). Should that “policy” be revisited? Is archival a synonym for bug closure? What are the reasons a bug report can or should be artificially archived by intervention? The Debian Social Contract (DSC) has a transparency clause: > 3. We will not hide problems > > We will keep our entire bug report database open for public view > at all times. Reports that people file online will promptly > become visible to others. That’s a good start but IMO it would improve quality if that were to go a step further and (by extension) state that open public /discussion/ of problems will also be facilitated. The archival of a bug report has the speech/idea-chilling effect of closing it and blocking further discussion. This bug report is motivated by another. I thought of a new feature that would improve the reportbug application. A search of bug reports showed that someone already put forward the same idea (bug 1002906). There’s more to say on that, so I responded. My contribution was suppressed because the bug was archived. In fact it was archived just a month or so after it was opened. Big transparency problem: even the verbose view of the bug report showing extraneous control messages gives no indication of /how/ or /why/ the bug was archived, or /who/ initiated it. We can only guess that based on the very short timeframe open that it was archived by intervention. Which means requesting unarchival goes against what I quoted from the server control page. I don’t imagine that whoever initiated the archival actually intended to suppress the discussion. It was likely maintainers looking to get the bug report out of their view (out of sight, out of mind) for organizational reasons. But since archival has the effect of suppressing discussion, it’s not a proper mechanism for that. ** Proposal ** I propose several actions to remedy all this. ① Revision to the DSC to include public discourse w.r.t bug reports. ② Drafting a clear and comprehensive policy informing everyone as to proper and improper usage of bug archival and unarchival. Adapt Bugs/server-control#unarchive as needed. ③ Modify the BTS as needed to include basic archival information in the public views of bug reports, such as: * who initiated the archival * why it was archived (age or intervention; and if intervention then the rationale for the intervention) ④ Reopen bug 1002906 if it’s deemed to have been archived without good cause.