launchpad-dev team mailing list archive

[curtis Hovey <curtis.hovey@xxxxxxxxxxxxx>]

On 05/11/2012 02:29 AM, Robert Collins wrote:
> On Fri, May 11, 2012 at 2:55 AM, curtis Hovey
> <curtis.hovey@xxxxxxxxxxxxx> wrote:
> ...
> 
> I have a few comments.
> 
> Firstly, I don't see why we would conflate subscription and access for
> any bugs; lets keep them clean and separate - even on a proprietary
> bug, a third party may have access, but not want all the chatter. They
> might be working a queue of bugs and have no desire or interest in
> discussion on a given bug until they come to it in their queue. Its
> not up to us to pre-decide this.

We are not conflating subscription and access. There is no use case for
bug-only access without subscription. The only case where a user needs
exceptional access to a bug is to participate in the conversation to fix
it. The UI does not need to be more complicated.

When a driver subscribes a user, Lp will check that the user has access
to the bug. If so, the subscription is added. If not, the UI will ask
the driver to [Share this Bug] or [Cancel]. We expect this confirmation
step will result in many cancel actions because this is also what
happens when Lp warns about assignments to non-contributors.

> Secondly, at the moment, we don't expand teams in the subscriber
> portlet; I don't think we should in a portlet for access grants
> either, because it will hide important information (that a specific
> non-Canonical person has a grant). If we don't expand teams, then a
> lot of your concerns about managability are significantly reduced, I
> think.

I absolutely do not want to expand teams. The bug page has too much
information. My goal it to have only the essential information.

> We don't show (3) at the moment, and we can't sensibly because who
> receives a notification depends on the actual change made (e.g.
> non-comment subscriptions). We do show the subscribers (without
> expansion); I think that that is arguably something we should have an
> expander for and not show by default, but even when we do, its still
> not a count of how many folk will be notified. I don't think we need
> such a count ever: when would someone make, or not make a change based
> on the number of potential recipients?

We don't need an accurate number for the very reason you state. An
approximate number might be more informative

> On 4, I think you are saying 'we do not need to list the teams that
> have been given role grants to the project on individual bugs'. I
> agree for proprietary bugs, but security and personal data bugs will
> still permit multiple-pillars, and for those it is much less clear
> what 'the project' means. I think we need to think about this more.

No. I want to see text like I propose.
    This bug is *proprietary*. Users the project has shared all
    proprietary information with can see this bug.

The information type portlet ~launchpad members see on bugs only states
that the bug contains embargoed security information, but it does not
tell me that the project must share that kind information for people to
get access.

Lp historically said this bug is private, and users assumed the project
maintainers and drivers could see the bug. Lp never said only the
subscribed users can see the bug. As a user reporting the bug, I do not
need to know who each project has chosen to share private information
with, I just need to know that the information is shared and that
someone who can fix my bug will see it.

> I don't understand point 5. it sounds like we're back to conflating
> access and subscription, which was a structure we specifically
> intended to unconflate - hopefully you can help me understand.

As above, the UI is simplified to support the one use case we were asked
to support. When we explained the expanded scope of introducing
information types to support the multiple policy implementation for
sharing, it was agreed to on the condition that we do not extend scope
to create new workflows for the bug page UI.

Bug-level access is an exception to project sharing rules. Knowing that
there are exceptions allows the project to learn if information is
compromised. In proprietary projects, we expect 99% of bugs to have no
exceptions. Some proprietary projects will employ contractors to work on
specific bugs, and when the contract is over, the exception should be
removed. In my own projects, I expect to see exceptions for the bug
reporter. Even in the case of a embargoed security bug shared by several
projects, I expect to see an exception for the bug reporter and maybe
one more for an expert advising on an upstream fix.


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

Attachment: signature.asc
Description: OpenPGP digital signature