need a way to be able to remove nuclear launch codes from comments on answers

Marking as "high" per recent LP/IS meeting.

I am marking this low because there is no one working these issues except for myself on weekends. This issue relates to bug 80895 and bug 201121.

The real problem is that these bugs are being reported on separate apps, which is exactly while there is a mediocre bug hiding script and not a way hide/edit comments on everything.

I'm bouncing this back up to high because its an operational problem.

The fact that answers is not well resourced doesn't alter the impact of the bug.

Making it high does not commit anyone to fix it either :( This send the message that this will get done if the community ignores it. I have strived to keep the status and importance in Launchpad Answers clear and honest. I do not trust the status and importance in other Launchpad projects--something that been high for 5 years and still have no commitments to be compete by a date on our calendar is a epic fail.

Lp engineers will only fix this when when the issue is both theirs and the problem is defined to be a common problem involving apps engineers are working on. The hide bug comment hack was *more* expensive to implement that just adding a visibility column to IMessage and providing ~registry with +edit on all IMessage (/me still advocates this after 18 months of watching teams develop competing partial solutions).

As a LOSA I would say "I will not run SQL to change comment, full stop". Then engineers have to stop work, re-prioritise, and make a solution that does not burden anyone else.

Perhaps we should take this to the list?

On Tue, Nov 2, 2010 at 7:38 AM, Curtis Hovey <email address hidden> wrote:
> Making it high does not commit anyone to fix it either :( This send the
> message that this will get done if the community ignores it.

I don't think it sends that message, because Launchpad bugs isn't
primarily a work queuing system. Importance is an amalgum of impact on
users and the relative priority the project community has given the
bug.

We can easily have bugs in high that noone touches for years, and low
ones that get done immediately. Our work queueing system is actually
Kanban, which further reinforces the disconnect. The impact on users
of being unable to remove data is significant. And the operational
impact is doing high risk operations.
...
> As a LOSA I would say "I will not run SQL to change comment, full stop".
> Then engineers have to stop work, re-prioritise, and make a solution
> that does not burden anyone else.

That would be a very hostile inter-team dynamic to observe, and I
would be very sad to see it happen. Our mutual jobs - LOSA + LP devs
requires meeting the needs of 4 groups: casual and power users,
operators and developers.

If we've been building poor implementations in silos, thats totally a
LP dev quirk and something we should just fix.

-Rob

I do not disagree with the severity of the issue :) I am arguing that chance of success is not being taken into consideration. We conflate Severity and Priority as Importance. Triage requires hard decisions--the most severe cases are not work first if the chances of success are poor. The chances of success are are still poor after *years* of discussion and hacking. We are still talking about a localised hack. This will be high when we can treat it as high.

I recognise I am forcefully driving this issue--I want a commitment to see this fixed in my lifetime. This issue is years old and marking it high and ignoring it does not help the LOSAs. I know that they should *never* be asked to work on data issues, this is an Registry Admin issue, not a System Admin issue. A policy change will elucidate the problem--Lp engineers will see that they have shot themselves in the foot and take appropriate action. Consider the number of closed CHR bugs...make the engineers experience the workflow, talk the the users who are injured by bad design, and they will re-prioritise to fix it.

We have 30 engineers watching 10 bugs relating to editing/deleting/hiding comments that belonh to 3 applications and 1 object that is used by all applications, include those that are not seen. This is not an Launchpad Answers bug, This is a Launchpad bug and the entire team should be committed to fixing this. I suggest we take it to the Thunderdome,but I will be happy to see it fixed before then.

I'm marking as a dupe, because an admin only comment-id based form could let one change solve both bugs.