yellow team mailing list archive

[Gary Poster <gary.poster@xxxxxxxxxxxxx>]

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

> 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:

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

>  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?

>  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.

> 
>  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.

> 
>  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.

> 
>  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.

> 
>  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.

> 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.

> 
> 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 :)

Absolutely.  We all felt that way a month ago.  Thank you for all your continued work. I hope you enjoy looking at some Translations bugs now. :-)

> 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).

We should tag all above bugs with "story-better-bug-notification" *and* "story-better-bug-notfication-rehash," (or similar) I think.

Here are some of my observations.

First, what do I think happened?

- I wanted the problem behind bug 772754 to be easy and small.  I identified the issue and raised it to Jono about midway through yellow squad's participation in the feature.  Discussion with him and Francis seemed to lead to an agreement that we could do something trivial.  However, QA work and end-result evaluation from the product team showed that this was in fact unacceptable.  This led to the biggest overrun of the project.

- We took much longer than expected on the entire feature.  Francis wanted us to move on to bug rotation because of this, despite the fact that we had two big bugs remaining--each of which was big enough to call a "sub feature," as we in fact did in kanban.

- I tried to skimp on user testing, since these were supposed to be quick fixes.  Since they were full "sub-features" the user testing probably would have been good (though see my frustrations on that at the end of the email). 

What might we learn from this?

- If we identify a task/bug as a "sub-feature" (multiple branches), the feature is not done, and we should not be sent to bug rotation.  The pressure to move off led to more waste: at the least, the team didn't focus together on the problem, and user testing was shafted.

- A corollary might be that anything that requires a UI mockup necessarily requires user testing, whatever the time pressure involved.

- I'd love to have more confidence in our understanding of whether the solution to a particular problem--for instance, what led to bug 772754--will be acceptable.  Perhaps two week delivery cycles are a sufficient solution.  I'm suspicious that they won't be, but I suppose we ought to give it a try first, since it's the obvious and planned next step.

Somewhat related observations:

- I'm frustrated by the rework/waste involved in our UI work caused by insufficient participation by UI experts.  Sub-points:
  * Even when we do user testing "right" AFAIK, we have gotten UI bugs from our UI experts that will lead to rework/waste (https://bugs.launchpad.net/launchpad/+bug/795180).  We've asked for UI expert participation and not received it in a timely or sufficient manner, as has been raised in the past.
  * Similarly, the Malone team had their UI user tested.  It was in progress, and I wanted to not touch it, so gmb proceeded with it.  This led to the mute part of the rework that Danilo and I did over the past several weeks: the user testing was insufficient.

I'll talk about all this with Francis tomorrow.  Please share any thoughts before then.

Gary