launchpad-dev team mailing list archive

[Robert Collins <robert.collins@xxxxxxxxxxxxx>]

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.

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.

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?

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.

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.

Cheers,
Rob