launchpad-dev team mailing list archive

[curtis Hovey <curtis.hovey@xxxxxxxxxxxxx>]

On 10/12/2011 10:14 AM, Aaron Bentley wrote:
> Is this separate from visibility policies?
It replaces visibility policies. This is a simpler model that we expect
users to understand. The complex visibility policy we have today is to
support multi-tenancy, which we are abandoning.
> > We do not want to reinvent a new UI to manage the creation/deletion
> > of polices.
>
> I don't understand how we can introduce a new concept to the user
> model, and not provide new UI to control it.
Policies were not in scope--stakeholders want private projects, not a
reimplementation of private bugs and branches. We are creating a
mechanism to give users access to the private data in projects and it is
easier to create a single mechanism and install it in the bugs and
branches than to make the existing feature behave like the new one.

The crux of the issue is that we only know of 3 policies based on what
is in Lp's code (privacy ad security), and apport (in Ubuntu's code and
lp's data). As I wrote elsewhere in the email, allowing users to create
policies requires a common definition of what they mean; that is scary,
and we do not have anyone paying us to make that kind of feature
> > Access is governed by policy, and notification is governed by
> > subscription.
>
> Nice to have that distinction, at last.
>
> > There will be default policies for new projects: Maintainer has
> > access to all security related project items. Maintainer has access
> > to all privacy related project items. The default maintainer is a
> > user or ~registry. We want to require teams that maintain projects
> > to be restricted or moderated.
>
> I imagine that some projects have a looser approach to privacy and
> security than that.  How do you imagine this system working for them?
Well, we control the definition, but I think you mean projects might
have moderated team and really do not vet who can join them.

*NEW*

We decided to *never* permit private or security bugs to have multiple
bugtargets. This is for both private and public projects. We decide in
Prague that private projects will not be permitted to have bugs that
affect more than one project. Bug links will solve that case where the
user needs to clone bugs to manage separate conversations. We had
planned to permit public projects to have private or security bugs that
affect more than one project. This is very hard to report, both to
describe who has access in the UI and to collect that data without
timing out. We decided that we simply will not permit private bugs to be
shared. We have looked at production data and are planning to advise the
stakeholders how to fix the cases that are already in Lp's data.

-- 
Curtis Hovey
http://launchpad.net/~sinzui

Attachment: signature.asc
Description: OpenPGP digital signature