← Back to team overview

yellow team mailing list archive

State of the bug subscription feature

 

Hi all,

This is the state of the bug subscription feature, with some still open
questions.  Please pardon the long email, but as someone (Pascal?) once
said, I don't have the time to make it shorter.

State
=====

 - New subscription portlet and list of subscribers is landed and in
stable

 - I've QAd it, but would like some more QA before I mark bug 772754 as
qa-ok (preferably some help from others) - I'd prefer not to deploy it
over the weekend but only on Monday (if one of the US folks can mark it
as qa-ok near the end of their day so it gets picked up early on Monday
be the far-east LOSA, that'd be great)

 - wgrant has found a problem (bug 798622) with JS failing to work for
anonymous users; fix is easy enough, but it does bring out the problem
that I consistently cause: I do not test my JS for anon users; as soon
as I start doing more *integration* tests, I am sure I'll be better at
it as well; this fix is in ec2 land already.

 - Feature flags are also removed: Benji's branch is merged in

 - I am hoping for a Monday rollout, but haven't arranged any
announcement yet; I'll probably write-up something on the blog (Matt
seems to be out today as well, though I only understood him to be out
next week)

Open issues
===========

In the "other subscribers" and "your subscription" portlets there are a
few regressions or open issues which I still haven't filed as bugs, as I
am not sure we care enough about them:

  1. There is no display name truncation anymore in the list (they used
to be truncated to 20 characters) - I am not particularly interested in
fixing this, but this is a very easy task: createSubscriberNode is what
needs changing.

  2. The portlet is sometimes too wide (because of "Notified when the
bug is closed or reopened" title, see eg.
https://bugs.qastaging.launchpad.net/ubuntu/+source/network-manager/+bug/152754 ); I believe this should be fixed in CSS if possible, but I don't care too much about this either

  3. I've excluded the showing of "subscribed by" from the title (it
used to be that you could hover over the subscriber name and see who
they were subscribed by); this is, probably, the most serious
regression, especially regarding the team subscriptions; I plan to file
a bug about this unless someone stops me

  4. If someone is already subscribed and listed in the subscribers list
at a level other than "receive all", the UI will behave as if their
subscription level has been changed to receive all emails; the change
will not happen (interestingly enough, "subscribe" AJAX call will
succeed, but the level won't be changed); this should be fixed as well

  5. Related to the above, if you "subscribe someone else" then pick
yourself, you will show up in the list as "notified of all changes" when
your subscription will actually is not modified (if you have one); we
should fix this, but I wonder if we should pretend to be smart or just
error out and let the user know that they should use different controls

  6. There is a potential for a UI race condition that the code is not
designed to handle (on purpose, due to my laziness): if a team you can
unsubscribe is subscribed, and you are able to quickly click
unsubscribe, then before the animation completes click on 'subscribe
someone else', find that same team, and subscribe them again, provided
subscribing succeeds after the end of the unsub animation, the just
unsubscribed, then subscribed team might not show up in the list, and
you might hit an error message from stopSubscriberActivity saying
something how addSubscriber needs to be called first; I tried to hit
this race condition, but I just couldn't be fast enough on qastaging or
localhost.  This explanation should indicate why I didn't bother with
it :)

  7. Brad has noted how he finds the edit icon in the middle of the
sentence weird in the "your subscription" portlet; I've talked with Matt
about us doing proper user testing for the feature, filing bugs as
usual, and then leaving the decision of "work on that or not" to the
higher powers :) Unfortunately, Matt is out next week, and I only
managed to get this landed Thursday night.

  8. Gary has commented how it'd be nice to provide some help text for
the "Maybe notified" section; I agree, but I haven't done that yet so I
could get it landed; Matt is willing to help with this (and some minor
user testing), but he is out next week.

  9. William was confused about how he can tell if someone is directly
subscribed, but I am willing to attribute that to him being too familiar
with the underlying concepts; he had an "ah" moment when I have shown
him a page with all sections listed.  Most bugs today will only have
"Notified of all changes" and "Maybe notified", which is where the
confusion might come from.  But it might still be an issue to look into.
Providing help as in 8 might have stopped William from getting confused
or at least confused as much.  Just like the explanatory text that Gary
included in the original mock-up attached to bug 772754 might have
helped.

 10. William was thoroughly unhappy with me landing a 12k-line branch.
I am not too happy about it either, but the fact that Gary's and my
branches were not feature flagged meant that we _had_ to drop it all
together on trunk, or we'd end up with some weirdness or other.  It did
cause some annoyances for me, as the late merge artefact caused test
failures, so I had to revert, investigate and then re-land the branch.

Conclusion
==========

For the things that we decide we want to take on ourselves, I'd prefer
not to be the only one working on it, since I feel like I need a break
from the bug subscription stuff :)

For the stuff we decide we don't want done, perhaps it's useful to share
them with Jono (useful when he does feature review) and the product team
(especially those doing the testing, like Diogo, Matt and Ursula).

Cheers,
Danilo




Follow ups