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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
