launchpad-dev team mailing list archive

[curtis Hovey <curtis.hovey@xxxxxxxxxxxxx>]

On 05/08/2012 01:38 AM, William Grant wrote:
> The second case is harder. We could require that artifact shares have a
> corresponding subscription, but that would still leave us without a way
> to display policy shares on the bug page. There appears to be no way out
> of this without UI changes. So we probably need a new portlet, or
> possibly an extension of the existing privacy portlet, but either would
> duplicate information from the subscription list.
> 
> It's also not clear whether unsubscribing should immediately revoke any
> explicit grant they may have. That's what happens in the old model.

The subscription-as-sharing use case exists so that projects can make
exceptions (from project-level sharing) for bug reporters and
contractors who will fix the bug. They do need to be subscribed. If the
person is not getting notifications, he or she is not helping to fix the
bug, thus the person does not need to access to the bug.

I do not think we want to show everyone who can see a private bug on the
bug page. Subscriber lists are often too long and unintelligible...the
subscribe-a-user feature returns early if it discovers the user is
already subscribed and does not tell the user that he failed to read the
subscriber list.

I think we need to rethink what extra information users need to know
because the side portlets have unchecked growth. We expect projects to
share private information with the team in project roles and the share
with an organisational team. A bug on a Canonical project may have 700
users who can see it.

1. I need to know if I am subscribed. It should be clear that I do or do
not get bug notifications.

2. I want to know by what means I am subscribed: directly, via a
structural subscription, via a team subscription, or via a team
structural subscription.

3. How many people may be notified of the change I am about to make. I
do not need to know their names...I do not know everyone who works for
Canonical.

4. Most Lp users (even Canonical staff) assume that people in project
roles can see the bug...this was never the case, but we will make it so
soon. The privacy portlet must tell me which privacy rules apply and who
can can see the bug because of the rules. eg.
    This bug is *proprietary*. Users the project has shared all
    proprietary information with can see this bug.
I do not need to know who those users are unless I am the maintainer or
driver...and they can use +sharing to see.

5. I want to know how many users the bug was specifically shared with
via a subscription (While bug subscriptions are separate from bug
access, you cannot have one without the other if the project is not
sharing with the user). Bug subscriptions, as a means of access for bug
reporters and contractors, are an exception to project rules that
interest me.

6. I may want to see the users who the bug was shared with because these
are the users I probably do not know, but the page does not need to show
that until I ask for it.

7. I may want to see the user who have direct subscriptions or
structural subscriptions because I want to check that my colleague will
be notified. The page does not need to show me the subscribers unless I
ask for it.

8. (extra credit) I am interested in knowing the number of duplicates.
The page does not need to show me the duplicated unless I ask for it.

Points 6 and 7 are the concerns of project maintainers and drivers.
Other users might be interested in who is notified, but they are not in
the position to judge of the person should or should not know of the
information, nor can they unsubscribe someone.

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

Attachment: signature.asc
Description: OpenPGP digital signature