yellow team mailing list archive

[Gary Poster <gary.poster@xxxxxxxxxxxxx>]

On Jun 20, 2011, at 10:43 AM, Gary Poster wrote:

> 
> On Jun 17, 2011, at 7:50 AM, Danilo Šegan wrote:

...

>> 
>> 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:
> 
> I'll file the bugs as I show them below.  

This email is the followup with the bug numbers.

> I'm mentioning them here first in case there's any discussion.
> 
>> 
>> 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.
> 
> Just another "Critical" bug with the "regression" tag, I think.  People on our squad can choose it or not--we no longer own this.

bug 799900

> 
>> 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
> 
> This causes a line break in the header for me, which works for me.  Maybe this is Epiphany-specific?
> 
>> 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
> 
> "Critical" "regression" that we don't own.  Out of curiosity, has someone complained about this?

bug 799901

> 
>> 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
> 
> "high" bug.

bug 799903

> 
>> 
>> 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
> 
> I'd prefer to simply not allow choosing yourself.  Maybe that's not easy, given that we are using a reusable widget (ah, that lovely idea of "reusability").
> 
> Anyway, "low" bug.

Made it high.  <shrug>

bug 799910

> 
>> 
>> 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 :)
> 
> :-)  "low" bug.

bug 799912

> 
>> 
>> 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.
> 
> "low" "ui" bug.  Highlight it to Huw and Jono, and move on.  They can decide what to do about it.

high <shrug>

bug 799914

> 
>> 
>> 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.
> 
> Maybe we can combine this into a "high" "ui" bug.  Also note broader observations below.

bug 799916.  I was not confident in the description of this bug or the previous one in particular.  Changes welcome.

> 
>> 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.
> 
> This was based on not doing the featureflag-in-email work.  I'm not sure what hindsight tells me yet, TBH.

I thought about filing a bug for featureflags in emails, because there's no immediate new need, and I figured that could be filed if someone practically wanted it in the future.

Gary