Assignee should be CC'd when assigneed to a private bug

Any objections to always making the assignee an explicitly subscriber?

Every other person that gets bug notifications is going to be explicitly Cc'd once InitialBugContacts lands so I don't see what the point of special-casing is here. And, in the case of, "what if you accidentally assign the bug to the wrong person?", well, the same question could be asked of the general subscription form.

On Wed, Dec 07, 2005 at 05:28:18PM -0000, Brad Bollenbach wrote:
> Public bug report changed:
> https://launchpad.net/malone/bugs/757
>
> Comment:
> Any objections to always making the assignee an explicitly subscriber?

One advantage of having the assignee as an implicit subscriber is in
the case of you assign the bug to me, and I decide that I don't have
time to work on the bug, so I assign someone else. Then I'm probably
not interested in the bug anymore, and don't want to get notifications
about it.

Personally, though, I think making the assignee an explicit subscriber
is the way to go. If we notice that it will cause some problem later, we
can always fix it then.

Hmmm. I get the impression that we change the assignee on a bug too frequently to have it simply be explicit. Some projects use the "reassign to blocker" model, and if we simply change the subscripion to be explicit we may end up with a list that is difficult to maintain.

I would vote for keeping it implicit unless we consider the effects carefully and decide it's okay, or that we need better UI to allow a person to unsubscribe while reassigning (yuck with our current model).

On 7-Dec-05, at 12:48 PM, Björn Tillenius wrote:

> Public bug report changed:
> https://launchpad.net/malone/bugs/757
>
> Comment:
> On Wed, Dec 07, 2005 at 05:28:18PM -0000, Brad Bollenbach wrote:
>> Public bug report changed:
>> https://launchpad.net/malone/bugs/757
>>
>> Comment:
>> Any objections to always making the assignee an explicitly
>> subscriber?
>
> One advantage of having the assignee as an implicit subscriber is in
> the case of you assign the bug to me, and I decide that I don't have
> time to work on the bug, so I assign someone else. Then I'm probably
> not interested in the bug anymore, and don't want to get notifications
> about it.

Yes, this is the cookie cutter response to implicit vs. explicit.
We've broken away from this model entirely based on decisions made
during UBZ discussions.

Diverging slightly (though this is still entirely relevant to
determining the best course of action for this bug):

In thinking more about these decisions from UBZ (explicit instead of
implicit), I'm wondering whether explicitness is going to be a world
of pain. :/ For example, I can't think of a reason on earth why
someone signing up to be a package bug contact would prefer that we
send them only all the bugmail from bugs opened /after/ they became a
contact vs. all bugs filed on that package. But that's what will
currently happen. Even if those bugs were opened a month before or an
hour before the became a bug contact. Also, if they unsubscribe as a
bug contact, they'll keep getting the bugmail of all the bugs that
were opened on that package during the time that they were the
contact (be it distro, package, or upstream.)

Of course, any use case (that I can think of) can still be addressed
with explicit subscriptions, it's just that it would need a lot more
UI to achieve it, making it easy to mass-subscribe/unsubscribe to
bugs given various parameters. I'm not sure if this is the path to
making users smile about Malone.

I think the next thing to do here is for me to re-read the use cases
outlined in the IBC spec and be sure that they're updated to describe
the user's goal as a would-be (or no-longer-wants-to-be) *contact and
be sure that the IBC implementation can address those concerns via
explicit subscriptions. If not, I fear a major rework may be in order.

What do you guys think?

Cheers,

--
Brad Bollenbach

Explicitness makes little sense not just for the reasons above, but also because it won't match what happens in the future for mail notifications about the various aspects of products and packages that don't have explicit subscriber lists (e.g. language translations, new branch creation, new sprint details). The IBC use cases don't cover the problems Björn and Brad described; they hardly cover workflow at all.

I spoke with Kamion about this, just to confirm the obvious. I will change IBC to use implicit subscriptions rather than explicit.

[Expired for Launchpad Bugs because there has been no activity for 60 days.]