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 -- Mailing list: https://launchpad.net/~yellow Post to : [email protected] Unsubscribe : https://launchpad.net/~yellow More help : https://help.launchpad.net/ListHelp
