Bug#1067053: qa.debian.org: Documented policy needed for bug archival + archival transparency needed
Package: qa.debian.org
Severity: normal
X-Debbugs-Cc: debbug.qa.debian.org@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.
Reply to: