launchpad-dev team mailing list archive

[Matthew Revell <matthew.revell@xxxxxxxxxxxxx>]

On 31 July 2012 15:02, Curtis Hovey <curtis.hovey@xxxxxxxxxxxxx> wrote:
> On 07/31/2012 06:23 AM, Matthew Revell wrote:
>>>>  * Once a private project is made public it's not just the bugs and
>>>> branches that need to stay private. At the least we also need to
>>>> consider Answers and Blueprints. What else?
>>>>
>>>>  * How can we tell people that their bug comment, for example, is
>>>> private and then later allow the project maintainer to expose it to
>>>> the world? Isn't that rather obnoxious?
>>>
>>> Well, the project maintainer could also copy and paste the comment into
>>> a public bug. We can't stop them from deliberately leaking it one way or
>>> another, so the question is not whether we should allow it, but rather
>>> whether we should arbitrarily make it more awkward. I suspect we shouldn't.
>>
>> I disagree. The act of copy and pasting a comment from a private bug
>> to a public bug requires conscious effort and gives a small chance for
>> the copy-paster to see something that shouldn't be made public. *That*
>> is deliberate.
>>
>> I suspect a blanket switch from private-->public wouldn't be quite as
>> deliberate as you're suggesting; it'd be too easy to skip over the
>> warnings, to check the check-box, to sign in triplicate that you
>> understand the consequences. Then we'd get complaints along the lines
>> of, "Oh my god, we've just unveiled Benji's secret plans to colonise
>> Mars, why did Launchpad let us do that?"
>
> We do not make automatically make private data public.

Right now, no. However, as we have no private projects yet and no
mechanism to take private projects public, I thought it was worth
stating why we don't want to take private information public.

> The emails we send to maintainers make it clear that information given
> in confidence stays private.
> Making a project public is about letting non-trusted people see the
> project and its selected bugs and branches so that a community can
> contribute.
> This is complicated by blueprints, questions, and translations that do
> not support privacy; either these artefacts will support privacy to
> maintainer our promise, or we block private project from using them, or
> we support deletion so that confidential information can be removed.

Stakeholders tell us that Translations and Answers are unnecessary for
their anticipated usage of private projects, so we can switch those
off.

Blueprints very much are necessary. Our plan is to allow blueprints
that were created under the assumption of privacy to remain private
once a project has gone public.

-- 
Matthew Revell
Product Manager, Launchpad and MAAS
Canonical

https://launchpad.net/~matthew.revell