launchpad-dev team mailing list archive

[Martin Pool <mbp@xxxxxxxxxxxxx>]

On 26 March 2011 05:56, Jonathan Lange <jml@xxxxxxxxxxxxx> wrote:
> Hello Launchpadders,
>
> I recently had a chat with the Kernel developers about how they use
> Launchpad. They posed me an interesting problem.
>
> They have bugs that they must keep public, for reasons of both
> principle and practicality. However, they don't really want anyone
> outside of an authorized set of people actually *doing* anything to
> those bugs. Outsiders change tags, statuses and add unhelpful comments
> and the Ubuntu developers would like to stop that from happening.
>
> What options do they have with Launchpad as it stands? What could we
> cheaply change in Launchpad to meet that need better?

I think it would be interesting and perhaps reasonably cheap to add
two checkboxes per bug: "lock status" and "lock comments".  They can
be changed by bug supervisors of any task.  If the former is set, task
fields (status, importance, etc) can't be changed and new tasks can't
be created, except by bug supervisors.  If the latter is set, comments
and attachments can't be added, again except by bug supervisors.
(Perhaps s/bug supervisors/some other role/; the intention being that
only developers can change it.)

I don't anticipate this would be set on many bugs but there are some
very hot bugs where it could be useful.

I like this idea because it may be a path to removing some special
case ACLs that exist at the moment (eg limits on moving into triage
state; wishes for limits on moving out of triage state; opinion state;
wishes for locking to wontfix).  Unlike those ACLs this can be put in
place only when something is actually a problem rather than slowing
down community triage in general.  (There is some similarity to
Wikipedia page protection.)

If combined with a final comment by a developer explaining where the
bug ought to be discussed, how people can express their desire it be
fixed, or what else people can do, it might help.

Martin