Re: Just Autoland It

[Andrew Halberstadt]

On 28/01/16 06:31 PM, Eric Rescorla wrote:

On Thu, Jan 28, 2016 at 10:58 AM, Gregory Szorc  wrote:


I'd like to thank everyone for the feedback in this thread. However, the
thread has grown quite long and has detoured from its original subject.

Speaking on behalf of everyone who works on MozReview, we know the
interface is lacking in areas and features are confusing or non-existent.
We're working on it. We're trying to morph workflows that have been
practiced at Mozilla for over a decade. We're playing a delicate balancing
game between giving familiarity with existing workflows (e.g. Bugzilla
integration) while trying to slowly nudge us towards more "modern" and more
powerful workflows.



Frankly, I'm a little dismayed to hear that you think that one of the goals
of Mozreview
is to modify people's workflows. The primary problem with our existing
review system
isn't that it doesn't involve some more "modern" review idiom (leaving
aside the question
of whether it is in fact more modern), but rather that the UI is bad and
that it's a lot
less powerful than existing review tools, including those that enact
basically the
same design (cf. Rietveld).

Speaking purely for myself, I'd be a lot happier if mozreview involved less
nudging
and morphing and more developing of basic functionality.

-Ekr


Not speaking to review per se, but engineering productivity in general.
The problem is there are so many unique and one-off workflows at Mozilla
that it gets harder and harder to improve "basic functionality" across
all of them. At some point, we hit vastly diminishing returns and get
stretched too thin. We'd love to improve every existing workflow, but
simply don't have the resources to do that.

Instead, we try to make one really nice workflow such that people want
to switch. That being said it's a valid opinion to think that the carrot
isn't sweet enough yet. If that's the case, filing bug reports like gps
mentioned is very helpful to us.

-Andrew



We're constantly surprised by all the one-off workflows and needs people
have and the reactions to a seemingly benign change. It's been a humbling
experience to say the least.

The best venue for reporting bugs, UX paper cuts, and suggest improvements
is Bugzilla. Developer Services :: MozReview. Or hop in #mozreview and chat
with us.

We get a lot of requests for changes that initially seem odd to us. So, if
your bug report could articulate why you want something and how many people
would benefit (e.g. "the layout team all does this"), it would help us
better empathize with your position and would increase the chances of your
request getting prioritized.


On Jan 28, 2016, at 10:14, Eric Rescorla  wrote:


On Thu, Jan 28, 2016 at 8:25 AM, Honza Bambas 

wrote:



On 1/28/2016 6:30, Karl Tomlinson wrote:

Honza Bambas writes:


On 1/25/2016 20:23, Steve Fink wrote:


For navigation, there's a list of changed files at the top
(below the fixed summary pane) that jumps to per-file anchors.

Not good enough for review process.

Are you saying you want tabs or something for this (like

splinter uses)? I'd certainly like something less sluggish, but
maybe that's just my browser again.

Yes please.  Having one file on the screen at a time is very
useful.

The next/previous file/comment keyboard shortcuts may be useful in
the meantime.


Unfortunately not.  The intention is that when I scroll down the screen
I'm at the end of *a single file*, and of course up the screen means to

be

up at that same file.  Shortcuts are definitely unhelpful for me.  With

how

revboard works now it's just a mess of all  put together.


I agree with this. As I've mentioned before, NSS uses Rietveld, which
file-by-file, and I find
this much more convenient.

-Ekr



Thanks anyway!

-hb-







https://www.reviewboard.org/docs/manual/2.5/users/reviews/reviewing-diffs/#keyboard-shortcuts

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform




___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Just Autoland It

[Eric Rescorla]

On Fri, Jan 29, 2016 at 6:22 AM, Andrew Halberstadt <
ahalberst...@mozilla.com> wrote:

> On 28/01/16 06:31 PM, Eric Rescorla wrote:
>
>> On Thu, Jan 28, 2016 at 10:58 AM, Gregory Szorc 
>> wrote:
>>
>> I'd like to thank everyone for the feedback in this thread. However, the
>>> thread has grown quite long and has detoured from its original subject.
>>>
>>> Speaking on behalf of everyone who works on MozReview, we know the
>>> interface is lacking in areas and features are confusing or non-existent.
>>> We're working on it. We're trying to morph workflows that have been
>>> practiced at Mozilla for over a decade. We're playing a delicate
>>> balancing
>>> game between giving familiarity with existing workflows (e.g. Bugzilla
>>> integration) while trying to slowly nudge us towards more "modern" and
>>> more
>>> powerful workflows.
>>>
>>
>>
>> Frankly, I'm a little dismayed to hear that you think that one of the
>> goals
>> of Mozreview
>> is to modify people's workflows. The primary problem with our existing
>> review system
>> isn't that it doesn't involve some more "modern" review idiom (leaving
>> aside the question
>> of whether it is in fact more modern), but rather that the UI is bad and
>> that it's a lot
>> less powerful than existing review tools, including those that enact
>> basically the
>> same design (cf. Rietveld).
>>
>> Speaking purely for myself, I'd be a lot happier if mozreview involved
>> less
>> nudging
>> and morphing and more developing of basic functionality.
>>
>> -Ekr
>>
>
> Not speaking to review per se, but engineering productivity in general.
> The problem is there are so many unique and one-off workflows at Mozilla
> that it gets harder and harder to improve "basic functionality" across
> all of them.


Well, the functionality that I hear people discussing and complaining about
with MozReview in this thread seems pretty common to most workflows:

- The ability to review individual files
- The ability to r- not just remove r+
- Concerns about how much context is included in the review.

All of these things are mostly just issues in the Mozreview UI.



> At some point, we hit vastly diminishing returns and get
> stretched too thin. We'd love to improve every existing workflow, but
> simply don't have the resources to do that.
>
> Instead, we try to make one really nice workflow such that people want
> to switch.


I think it's clear from this thread that that has not succeeded.

More generally, I keep seeing comments (especially from GPS) about
trying to push people towards some workflow that's different from the
patch-based workflow that's the modal bugzilla workflow that I suspect
most people now use. That doesn't seem like an especially valuable
goal for this work.

-Ekr

That being said it's a valid opinion to think that the carrot
> isn't sweet enough yet. If that's the case, filing bug reports like gps
> mentioned is very helpful to us.
>
> -Andrew
>
>
>
> We're constantly surprised by all the one-off workflows and needs people
>>> have and the reactions to a seemingly benign change. It's been a humbling
>>> experience to say the least.
>>>
>>> The best venue for reporting bugs, UX paper cuts, and suggest
>>> improvements
>>> is Bugzilla. Developer Services :: MozReview. Or hop in #mozreview and
>>> chat
>>> with us.
>>>
>>> We get a lot of requests for changes that initially seem odd to us. So,
>>> if
>>> your bug report could articulate why you want something and how many
>>> people
>>> would benefit (e.g. "the layout team all does this"), it would help us
>>> better empathize with your position and would increase the chances of
>>> your
>>> request getting prioritized.
>>>
>>> On Jan 28, 2016, at 10:14, Eric Rescorla  wrote:

 On Thu, Jan 28, 2016 at 8:25 AM, Honza Bambas 
>
 wrote:
>>>

> On 1/28/2016 6:30, Karl Tomlinson wrote:
>>
>> Honza Bambas writes:
>>
>> On 1/25/2016 20:23, Steve Fink wrote:
>>>
>>> For navigation, there's a list of changed files at the top
 (below the fixed summary pane) that jumps to per-file anchors.

>>> Not good enough for review process.
>>>
>>> Are you saying you want tabs or something for this (like
>>>
 splinter uses)? I'd certainly like something less sluggish, but
 maybe that's just my browser again.

>>> Yes please.  Having one file on the screen at a time is very
>>> useful.
>>>
>> The next/previous file/comment keyboard shortcuts may be useful in
>> the meantime.
>>
>
> Unfortunately not.  The intention is that when I scroll down the screen
> I'm at the end of *a single file*, and of course up the screen means to
>
 be
>>>
 up at that same file.  Shortcuts are definitely unhelpful for me.  With
>
 how
>>>
 revboard works now it's just a mess of all  put together.
>

 I agree with this. As I've 

Re: Just Autoland It

[Mark Côté]

On 2016-01-29 10:27 AM, Eric Rescorla wrote:
> On Fri, Jan 29, 2016 at 6:22 AM, Andrew Halberstadt <
> ahalberst...@mozilla.com> wrote:
> 
>> On 28/01/16 06:31 PM, Eric Rescorla wrote:
>>
>>> On Thu, Jan 28, 2016 at 10:58 AM, Gregory Szorc 
>>> wrote:
>>>
>>> I'd like to thank everyone for the feedback in this thread. However, the
 thread has grown quite long and has detoured from its original subject.

 Speaking on behalf of everyone who works on MozReview, we know the
 interface is lacking in areas and features are confusing or non-existent.
 We're working on it. We're trying to morph workflows that have been
 practiced at Mozilla for over a decade. We're playing a delicate
 balancing
 game between giving familiarity with existing workflows (e.g. Bugzilla
 integration) while trying to slowly nudge us towards more "modern" and
 more
 powerful workflows.

>>>
>>>
>>> Frankly, I'm a little dismayed to hear that you think that one of the
>>> goals
>>> of Mozreview
>>> is to modify people's workflows. The primary problem with our existing
>>> review system
>>> isn't that it doesn't involve some more "modern" review idiom (leaving
>>> aside the question
>>> of whether it is in fact more modern), but rather that the UI is bad and
>>> that it's a lot
>>> less powerful than existing review tools, including those that enact
>>> basically the
>>> same design (cf. Rietveld).
>>>
>>> Speaking purely for myself, I'd be a lot happier if mozreview involved
>>> less
>>> nudging
>>> and morphing and more developing of basic functionality.
>>>
>>> -Ekr
>>>
>>
>> Not speaking to review per se, but engineering productivity in general.
>> The problem is there are so many unique and one-off workflows at Mozilla
>> that it gets harder and harder to improve "basic functionality" across
>> all of them.
> 
> 
> Well, the functionality that I hear people discussing and complaining about
> with MozReview in this thread seems pretty common to most workflows:
> 
> - The ability to review individual files
> - The ability to r- not just remove r+
> - Concerns about how much context is included in the review.
> 
> All of these things are mostly just issues in the Mozreview UI.

Yes absolutely, many of the UI problems are not really about workflow.

>> At some point, we hit vastly diminishing returns and get
>> stretched too thin. We'd love to improve every existing workflow, but
>> simply don't have the resources to do that.
>>
>> Instead, we try to make one really nice workflow such that people want
>> to switch.
> 
> 
> I think it's clear from this thread that that has not succeeded.
> 
> More generally, I keep seeing comments (especially from GPS) about
> trying to push people towards some workflow that's different from the
> patch-based workflow that's the modal bugzilla workflow that I suspect
> most people now use. That doesn't seem like an especially valuable
> goal for this work.

So, the only workflow that's really baked into MozReview, which I've
talked about before, is the idea of microcommits: that authors should be
splitting their work up into small, atomic commits, and updating them as
they get reviews.  I actually argue that this isn't even a workflow per
se.  It's more of a design principle of how software should be built.
It's my understanding that the senior engineers at Mozilla agree with
this principle, which is why supporting microcommits was a goal from the
beginning, back when Taras and Ehsan and a couple others agreed that we
needed a new tool and starting collecting requirements.

The downside is that no other code-review tool out there really does
this approach well, so we had to pick one (that could support both hg
and git) and build on it.  It's been (clearly) tough to get this right,
with all the confusion over squashed diffs and review summaries and
such.  A lot of the feedback here has been really constructive, though,
so one way or another we're going to get to something that will make
people a lot happier.  I'll be sure to ask for feedback on our design
ideas as we proceed.

Mark

> 
> -Ekr
> 
> That being said it's a valid opinion to think that the carrot
>> isn't sweet enough yet. If that's the case, filing bug reports like gps
>> mentioned is very helpful to us.
>>
>> -Andrew
>>
>>
>>
>> We're constantly surprised by all the one-off workflows and needs people
 have and the reactions to a seemingly benign change. It's been a humbling
 experience to say the least.

 The best venue for reporting bugs, UX paper cuts, and suggest
 improvements
 is Bugzilla. Developer Services :: MozReview. Or hop in #mozreview and
 chat
 with us.

 We get a lot of requests for changes that initially seem odd to us. So,
 if
 your bug report could articulate why you want something and how many
 people
 would benefit (e.g. "the layout team all does this"), it would help us
 better empathize with your 

Re: Just Autoland It

[Dave Townsend]

On Fri, Jan 29, 2016 at 7:27 AM, Eric Rescorla  wrote:
> On Fri, Jan 29, 2016 at 6:22 AM, Andrew Halberstadt <
> ahalberst...@mozilla.com> wrote:
>
>> On 28/01/16 06:31 PM, Eric Rescorla wrote:
>>
>>> On Thu, Jan 28, 2016 at 10:58 AM, Gregory Szorc 
>>> wrote:
>>>
>>> I'd like to thank everyone for the feedback in this thread. However, the
 thread has grown quite long and has detoured from its original subject.

 Speaking on behalf of everyone who works on MozReview, we know the
 interface is lacking in areas and features are confusing or non-existent.
 We're working on it. We're trying to morph workflows that have been
 practiced at Mozilla for over a decade. We're playing a delicate
 balancing
 game between giving familiarity with existing workflows (e.g. Bugzilla
 integration) while trying to slowly nudge us towards more "modern" and
 more
 powerful workflows.

>>>
>>>
>>> Frankly, I'm a little dismayed to hear that you think that one of the
>>> goals
>>> of Mozreview
>>> is to modify people's workflows. The primary problem with our existing
>>> review system
>>> isn't that it doesn't involve some more "modern" review idiom (leaving
>>> aside the question
>>> of whether it is in fact more modern), but rather that the UI is bad and
>>> that it's a lot
>>> less powerful than existing review tools, including those that enact
>>> basically the
>>> same design (cf. Rietveld).
>>>
>>> Speaking purely for myself, I'd be a lot happier if mozreview involved
>>> less
>>> nudging
>>> and morphing and more developing of basic functionality.
>>>
>>> -Ekr
>>>
>>
>> Not speaking to review per se, but engineering productivity in general.
>> The problem is there are so many unique and one-off workflows at Mozilla
>> that it gets harder and harder to improve "basic functionality" across
>> all of them.
>
>
> Well, the functionality that I hear people discussing and complaining about
> with MozReview in this thread seems pretty common to most workflows:
>
> - The ability to review individual files
> - The ability to r- not just remove r+
> - Concerns about how much context is included in the review.
>
> All of these things are mostly just issues in the Mozreview UI.
>
>
>
>> At some point, we hit vastly diminishing returns and get
>> stretched too thin. We'd love to improve every existing workflow, but
>> simply don't have the resources to do that.
>>
>> Instead, we try to make one really nice workflow such that people want
>> to switch.
>
>
> I think it's clear from this thread that that has not succeeded.

No-one has claimed that the work to make that nice workflow is done yet.

> More generally, I keep seeing comments (especially from GPS) about
> trying to push people towards some workflow that's different from the
> patch-based workflow that's the modal bugzilla workflow that I suspect
> most people now use. That doesn't seem like an especially valuable
> goal for this work.

I disagree. The workflow everyone is used to is the workflow that
bugzilla essentially forces on us. Given the choice is it the workflow
everyone would use? For some maybe but given how many people I see
using mozreview now (even though it still has its problems) when the
old workflow is still perfectly usable suggests that this new workflow
is preferable to many and so this work is valuable. Some issues aside
I find it much more more straightforward to use.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Just Autoland It

[Boris Zbarsky]

On 1/29/16 10:42 AM, Mike Conley wrote:

most of the feedback is via negativa[2]


That's definitely no good, I agree.

Attacking the MozReview team is also not ok, obviously.


and nobody is really forcing you to use MozReview.


Well, sort of.  A review requester who uses Mozreview is forcing the 
review requestee to use MozReview to some extent.


That said, I've seen some review requestees blanket unset review flags 
on any MozReview request, in an attempt to get review requests they 
actually want to deal with.


Note that either way there is bad feeling here as a result: either the 
review requestee feels like the review requester is forcing them into a 
bad workflow, or the review requester feels like the review requestee is 
forcing them into a bad workflow.


Since making the review requester feel crappy is not generally 
considered good, most review requestees don't push back on MozReview 
requests, even if they find it very frustrating to work with.  I think 
this dynamic is at the heart of a lot of the angst about MozReview: 
people just feel put upon.



I see teams using GitHub pull requests, Reviewable, Opera
Critic, Reitveld, and Splinter in parallel with MozReview.


This works well in reasonably isolated team.

As you might have noticed, the people who seem to be complaining about 
MozReview the most are the ones who (1) do a lot of reviews and (2) do 
them across a wide swath of the codebase.  Item (1) means they already 
have a well-worked out review workflow, and MozReview would initially be 
slower and more annoying even if the UI were perfect.  It also means 
that they represent a disproportionate portion of all the reviews 
done.[1]  Item (2) means they can't just ask all the potential review 
requesters to not use MozReview, because asking a review requester to 
remember the preferred review system on a per-requestee basis is nuts.


So there's some combination of "this is different" and "this is worse" 
here, and as usual disentangling them is a bit hard.  As you say, 
concrete bug reports are the way to go.



are - this is where filed bugs come in[4]).


As a personal anecdote, in the last 5 months I've reported what looks 
like 7 bugs that significantly affect my ability to use MozReview 
effectively, and there is one more that I would have reported were it 
not reported already.  Of these, two have been addressed.  I'm not 
blaming the MozReview team here; they have limited resources, other 
commitments, and I can't be the only person reporting bugs!  But, again, 
we end up with a dynamic where people are effectively being told "use 
it; if you run into issues, file bugs and keep using it", but the bugs 
take a long time to address and in the meantime using it is frustrating. 
 Again, not the fault of the MozReview team, but that doesn't make the 
frustration less.


I agree that if people were not feeling forced into using it and could 
just report the bugs and then wait for them to be fixed while using 
something else, they would be a lot less worked up around this.



Try MozReview. If it doesn't work for you, maybe use something else, and
try it again in a few months once the team has had a chance to address
the bugs you hopefully filed.


This is reasonable advice for review requesters, but not for review 
requestees, per above.  :(


The bad news is that I don't know what advice to give requestees, 
including myself, here.  What I've been doing personally is just the 
"stop, take a deep breath, relax" routine whenever I get a mozreview 
request, but the fact that the routine is necessary is a bummer...



Again, I mean no disrespect here. I just want to gently suggest that we
exercise some restraint while hammering on the MozReview team


Fully agreed, and apologies if I've said things that came across that way.

-Boris

[1] To quantify this, if smaug is doing 6 reviews (bugs, not changesets; 
more changesets) per calendar day, then a set of UI annoyances that adds 
5 minutes per review is a big deal: that's 3.5 hours out of his work 
week.  It's obviously a less big deal for someone doing one review every 
three days.  I did not make up the numbers for smaug, and we have plenty 
of people who average one review every few days, for sure...


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Just Autoland It

[Mike Conley]

I respect everybody talking in this thread a great deal, but I thought I
might gently suggest that folks exercise a bit of empathy for what the
MozReview team[1] are trying to accomplish, and how difficult that work
actually is.

Trying to build a tool that satisfies such a wide spectrum of
preferences is extremely difficult - especially when (it seems to me)
most of the feedback is via negativa[2]. Having worked on front-end for
Firefox for a number of years, I believe I can speak with a certain
degree of authority about how difficult it is to satisfy users with UI
and workflow. It's a hard problem. Perhaps this can be alleviated by
putting some UX folks on the problem[3].

The good news is that this is Mozilla, which means that there are a
variety of ways of doing things, and nobody is really forcing you to use
MozReview. I see teams using GitHub pull requests, Reviewable, Opera
Critic, Reitveld, and Splinter in parallel with MozReview. Each have
their strengths. The thing with MozReview, however, is that we can more
easily mold it to suit our needs (once we can settle on what those needs
are - this is where filed bugs come in[4]).

Try MozReview. If it doesn't work for you, maybe use something else, and
try it again in a few months once the team has had a chance to address
the bugs you hopefully filed.

Again, I mean no disrespect here. I just want to gently suggest that we
exercise some restraint while hammering on the MozReview team, who are
trying to accomplish something extremely difficult.

-Mike

[1]: I'm not on the MozReview team, but I've been involved peripherally
from the outset, and I'm also a Review Board contributor.
[2]: This has different meanings for different people, but I'm using it
in the stage-theatre sense, where a director will not tell you what they
want, but every time you come out with something, they'll tell you what
you need to stop doing without telling you what you need to do. As an
actor, I always found this directing technique to be extremely frustrating.
[3]: There have been some casual consultations with folks like bwinton,
but I think that's about as far as it goes.
[4]: The MozReview team triages these biweekly (I believe), so they'll
get read and considered.

On 29/01/2016 9:22 AM, Andrew Halberstadt wrote:
> On 28/01/16 06:31 PM, Eric Rescorla wrote:
>> On Thu, Jan 28, 2016 at 10:58 AM, Gregory Szorc 
>> wrote:
>>
>>> I'd like to thank everyone for the feedback in this thread. However, the
>>> thread has grown quite long and has detoured from its original subject.
>>>
>>> Speaking on behalf of everyone who works on MozReview, we know the
>>> interface is lacking in areas and features are confusing or
>>> non-existent.
>>> We're working on it. We're trying to morph workflows that have been
>>> practiced at Mozilla for over a decade. We're playing a delicate
>>> balancing
>>> game between giving familiarity with existing workflows (e.g. Bugzilla
>>> integration) while trying to slowly nudge us towards more "modern"
>>> and more
>>> powerful workflows.
>>
>>
>> Frankly, I'm a little dismayed to hear that you think that one of the
>> goals
>> of Mozreview
>> is to modify people's workflows. The primary problem with our existing
>> review system
>> isn't that it doesn't involve some more "modern" review idiom (leaving
>> aside the question
>> of whether it is in fact more modern), but rather that the UI is bad and
>> that it's a lot
>> less powerful than existing review tools, including those that enact
>> basically the
>> same design (cf. Rietveld).
>>
>> Speaking purely for myself, I'd be a lot happier if mozreview involved
>> less
>> nudging
>> and morphing and more developing of basic functionality.
>>
>> -Ekr
> 
> Not speaking to review per se, but engineering productivity in general.
> The problem is there are so many unique and one-off workflows at Mozilla
> that it gets harder and harder to improve "basic functionality" across
> all of them. At some point, we hit vastly diminishing returns and get
> stretched too thin. We'd love to improve every existing workflow, but
> simply don't have the resources to do that.
> 
> Instead, we try to make one really nice workflow such that people want
> to switch. That being said it's a valid opinion to think that the carrot
> isn't sweet enough yet. If that's the case, filing bug reports like gps
> mentioned is very helpful to us.
> 
> -Andrew
> 
> 
>>> We're constantly surprised by all the one-off workflows and needs people
>>> have and the reactions to a seemingly benign change. It's been a
>>> humbling
>>> experience to say the least.
>>>
>>> The best venue for reporting bugs, UX paper cuts, and suggest
>>> improvements
>>> is Bugzilla. Developer Services :: MozReview. Or hop in #mozreview
>>> and chat
>>> with us.
>>>
>>> We get a lot of requests for changes that initially seem odd to us.
>>> So, if
>>> your bug report could articulate why you want something and how many
>>> people
>>> would benefit 

Re: Just Autoland It

[Mike Conley]

>> Since making the review requester feel crappy is not generally
>> considered good, most review requestees don't push back on MozReview
>> requests, even if they find it very frustrating to work with.  I think
>> this dynamic is at the heart of a lot of the angst about MozReview:
>> people just feel put upon.

That's a good point. From my observations and interactions with the
MozReview team over the months, I believe a great deal of the initial
effort has been to lower the ramp for the requestors, as opposed to the
requestees. The fact that we're seeing so many review requests go
through MozReview might be a sign of success in terms of that work.

Anecdotal evidence, along with the sentiments in threads like this (and
elsewhere) suggests that it would now probably be worth shifting the
emphasis on lowering the ramp for the requestees.

I do know that this sort of work has started to get attention from the
MozReview team. smaug, as the most prolific reviewer[1] recently filed a
bug about interdiffs being busted in particular cases, and it's getting
serious attention from the team.

So, I guess we need to show some empathy for the requestees as well. I
think[2] it's not always clear what the most critical thing to fix for
our requestees is. If folks have some wireframes, ascii diagrams,
napkins sketches, I'm certain the MozReview team would find that valuable.

[1]: All hail the mighty smaug!
[2]: Beyond obvious things like, "interdiffs are sometimes wrong", which
is clearly something to fix ASAP

On 29/01/2016 11:18 AM, Boris Zbarsky wrote:
> On 1/29/16 10:42 AM, Mike Conley wrote:
>> most of the feedback is via negativa[2]
> 
> That's definitely no good, I agree.
> 
> Attacking the MozReview team is also not ok, obviously.
> 
>> and nobody is really forcing you to use MozReview.
> 
> Well, sort of.  A review requester who uses Mozreview is forcing the
> review requestee to use MozReview to some extent.
> 
> That said, I've seen some review requestees blanket unset review flags
> on any MozReview request, in an attempt to get review requests they
> actually want to deal with.
> 
> Note that either way there is bad feeling here as a result: either the
> review requestee feels like the review requester is forcing them into a
> bad workflow, or the review requester feels like the review requestee is
> forcing them into a bad workflow.
> 
> Since making the review requester feel crappy is not generally
> considered good, most review requestees don't push back on MozReview
> requests, even if they find it very frustrating to work with.  I think
> this dynamic is at the heart of a lot of the angst about MozReview:
> people just feel put upon.
> 
>> I see teams using GitHub pull requests, Reviewable, Opera
>> Critic, Reitveld, and Splinter in parallel with MozReview.
> 
> This works well in reasonably isolated team.
> 
> As you might have noticed, the people who seem to be complaining about
> MozReview the most are the ones who (1) do a lot of reviews and (2) do
> them across a wide swath of the codebase.  Item (1) means they already
> have a well-worked out review workflow, and MozReview would initially be
> slower and more annoying even if the UI were perfect.  It also means
> that they represent a disproportionate portion of all the reviews
> done.[1]  Item (2) means they can't just ask all the potential review
> requesters to not use MozReview, because asking a review requester to
> remember the preferred review system on a per-requestee basis is nuts.
> 
> So there's some combination of "this is different" and "this is worse"
> here, and as usual disentangling them is a bit hard.  As you say,
> concrete bug reports are the way to go.
> 
>> are - this is where filed bugs come in[4]).
> 
> As a personal anecdote, in the last 5 months I've reported what looks
> like 7 bugs that significantly affect my ability to use MozReview
> effectively, and there is one more that I would have reported were it
> not reported already.  Of these, two have been addressed.  I'm not
> blaming the MozReview team here; they have limited resources, other
> commitments, and I can't be the only person reporting bugs!  But, again,
> we end up with a dynamic where people are effectively being told "use
> it; if you run into issues, file bugs and keep using it", but the bugs
> take a long time to address and in the meantime using it is frustrating.
>  Again, not the fault of the MozReview team, but that doesn't make the
> frustration less.
> 
> I agree that if people were not feeling forced into using it and could
> just report the bugs and then wait for them to be fixed while using
> something else, they would be a lot less worked up around this.
> 
>> Try MozReview. If it doesn't work for you, maybe use something else, and
>> try it again in a few months once the team has had a chance to address
>> the bugs you hopefully filed.
> 
> This is reasonable advice for review requesters, but not for review
> requestees, per above.  :(
> 
> 

IPDL syntax change

[Bill McCloskey]

Hi everyone,
In bug 1240871 , we
changed the syntax for IPDL to require an explicit message type annotation.
Previously you could write the following:

FooMessage(nsString arg);

and it would be an async message by default. That was a bit confusing
because you could also write

async FooMessage(nsString arg);

to get the same thing. Some files had both forms just because different
people wrote them.

Now you're required to use the second form. Everything in the tree has been
fixed accordingly. If you have patches using the old form, something like
this regular expression might help:

s/(^[ ]*)([A-Z_][a-zA-Z0-9_]*\()/$1async $2/

However, it's probably easier to fix this manually since IPDL changes are
usually pretty small.

-Bill
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Just Autoland It

[Boris Zbarsky]

On 1/29/16 11:18 AM, Boris Zbarsky wrote:

This is reasonable advice for review requesters, but not for review
requestees, per above.  :(


That said, I guess most of this thread has been from the requester point 
of view, not the requestee.  The main dynamic here seems to be that 
people who might not be actively using MozReview yet are interested, and 
want to make sure it will be able to do what they want to do.  The fact 
that they're not actively using it or involved in its development means 
they don't quite have a clear grasp on what the end goal is in terms of 
UX.  I know I don't.  So they're not communicating their concerns very 
clearly, because their concerns are unclear to themselves in large part.


At least for some people, I think this is compounded by a general sense 
of frustration with MozReview from the requestee point of view, which is 
bleeding over in an undesirable way...


-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Just Autoland It

[Eric Rescorla]

On Fri, Jan 29, 2016 at 8:12 AM, Dave Townsend 
wrote:

> On Fri, Jan 29, 2016 at 7:27 AM, Eric Rescorla  wrote:
>
> More generally, I keep seeing comments (especially from GPS) about
> > trying to push people towards some workflow that's different from the
> > patch-based workflow that's the modal bugzilla workflow that I suspect
> > most people now use. That doesn't seem like an especially valuable
> > goal for this work.
>
> I disagree. The workflow everyone is used to is the workflow that
> bugzilla essentially forces on us. Given the choice is it the workflow
> everyone would use? For some maybe but given how many people I see
> using mozreview now (even though it still has its problems) when the
> old workflow is still perfectly usable suggests that this new workflow
> is preferable to many and so this work is valuable. Some issues aside
> I find it much more more straightforward to use.
>

It's important to separate issues of workflow from issues of UI. I still
prefer
Mozreview for significant-sized Gecko patches despite the general clunkiness
of the workflow because ReviewBoard is so much better at showing what
changed than splinter is. But when I have a choice (e.g., for isolated
projects like NSS) I use Rietveld and when it's small I use Splinter,
because
I find them generally easier to work with.

-Ekr
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Does SSE2 usage still need to be conditional?

[Ashley Gullen]

FWIW, the Steam Hardware Survey says 99.99% of users have SSE2 (under
"other settings"): http://store.steampowered.com/hwsurvey


On 28 January 2016 at 18:35, Henri Sivonen  wrote:

> It's been a while since the previous SSE2 thread.
>
> I have some questions:
>  * Does Firefox (for Windows and Linux) still run on non-SSE2 hardware?
>  * If it does, do the usage statistics justify it continuing to do so?
>  * Do Linux distros that ship Firefox by default run on non-SSE2 hardware?
>  * Do we already use SSE2 code paths unconditionally on x86_64? (I
> gather SSE2 is a non-optional part of x86_64.)
>  * Does Chrome run on non-SSE2 hardware? What about Chromium?
>
> In other words, can SSE2-enablement now be a compile-time thing or
> does it still need to be a run-time thing?
> --
> Henri Sivonen
> hsivo...@hsivonen.fi
> https://hsivonen.fi/
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Bug Program Next Steps

[Emma Humphries]

Bug Program Next Steps

Over the last week, I’ve asked you to step up and identify developers who
will be responsible for bugs triaged into their component (in Firefox,
Core, Toolkit, Fennec iOS, and Fennec Android.)
Why This Matters

Bugs are a unit of quality we can use to see how we’re doing.

We believe that the number of outstanding, actionable bugs is the best
metric of code quality available, and that how this number changes over
time will be a strong indicator of the evolving quality of Firefox.
Actionable bugs are those with the status NEW for which the next action
required - if any - is unambiguous: does the bug need immediate attention,
will it be worked on for a future release, will it be worked on at all?

There are two parts to maintaining the value of that metric. First, we want
to make better assertions about the quality of our releases by making clear
decisions about which bugs must be fixed for each release (urgent) and
actively tracking those bugs. The other is the number of good bugs filed by
our community. Filing a bug report is a gateway to greater participation in
the Mozilla project, and we owe it to our community to make quick and clear
decisions about each bug.

Making decisions on new bugs quickly helps us avoid point releases, and
gives positive feedback to people filing bugs so that they will file more
good bugs.
What’s Your Role

Starting in the second quarter of this year, if you’ve taken on a
component, I’m expecting you or your team to look at the bugs which landed
in the component on a more frequent basis than a weekly triage.

In February, we’re starting a pilot with four groups of components where
we’ll get the process changes and field tested, so that we can we can take
the changes to all the affected bugzilla components for review and comment
before we implement them across all of the work on Firefox.
Hold on, we already have a weekly triage!

That’s fantastic, but a weekly pace means we miss bugs that affect upcoming
releases. So I’m expecting you to scan that list of inbound bugs daily for
the urgent ones (I’ll define urgent below) and put them into one of the
states described in the next section, the others can go into your regular
triage.
At Your Regular Triage

You’ll look at the bugs which landed in your component and decide on how to
act on them using the states described in the next section.
We don’t have a regular triage

This is a process which you’ll need to start, and the bug program team will
help with this.
This is potentially a lot of work for one person

Looking at the urgent bugs does not have to be one person’s task. You can
have a rotation of people doing this. Look at the Core::Graphics
 triage wiki for an
example of what you could be doing.
Bug States

Initially, these states will be marked in bugzilla.mozilla.org using
whiteboard tags during the pilot. The bugzilla team will be making further
changes once we’ve settled on a process.

You’ll be looking at bugs in your component as they land, in your
component. We expect most of these will be NEW bugs, but some will be in
UNCONFIRMED.

There are four states you’ll need to decide to put each bug, and in your
reviews between your team’s weekly triages, we want you to be on the watch
for bugs with characteristics which make getting it in front of someone
urgent: these are bugs with crash, topcrash, regression, or dataloss
keywords; crash logs linked in comments; references to mozregression
results; and others.

The bug should not remain in this state after your review of it.

You’ll need to decide which of the following states you’ll move this bug
into, if you can’t you’ll need to be taking action: such as getting someone
to run mozregression, need info’ing a domain expert, looking at checkins,
and whatever else techniques you have to get a bug reduced.

Once you have an understanding of the bug, you should assign it to one of
these states.
Urgent

Assigned to a developer, release tracking flags nominated, and set at
priority `P1`. If the bug is being worked on by somebody from outside your
core team, a team mentor should be assigned.

All these need to be set for the bug when you assign it to this state. This
state is for bugs you find in your daily review which need a developer
immediately.

If the bug is not in need of immediate attention, then your team’s process
should land the bug in one of the following states.
Backlog

This is a NEW bug that the team acknowledges is a bug, but is not a current
priority, but will consider taking on. If the bug contains regression,
crash, topcrash, or similar keywords and metadata, then the team can
explain why it’s not a high priority.
Is a Bug, Not Prioritized

This is a terminal state for a NEW bug. We acknowledge the bug exists, it
affects people, but it is not important enough to warrant working on it.
The team will review and accept patches from the community for this bug
report.
Closed

This is a 

Re: Bug Program Next Steps

[Eric Rescorla]

On Fri, Jan 29, 2016 at 3:53 PM, Kyle Huey  wrote:

> On Fri, Jan 29, 2016 at 3:45 PM, Emma Humphries  wrote:
>
>> We believe that the number of outstanding, actionable bugs is the best
>> metric of code quality available, and that how this number changes over
>> time will be a strong indicator of the evolving quality of Firefox.
>>
>
> Why do we believe that?
>

I trust we are excluding bugs which are actually feature requests.

-Ekr


>
> - Kyle
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Bug Program Next Steps

[Emma Humphries]

Richard,

Many components have watchers, I am grateful for that. Some components
don't. We need reviews in all components so we don't lose track of bugs we
must fix to avoid a point release.

We're applying consistent process across all components, because we must
reduce the amount of noise in bugzilla. Anyone should be able to see what
we are doing, what we agree to do later, and what we're not going to do and
not have to know the metadata folklore of each component to do it. This
means there's going to be changes in how teams use bugzilla metadata.

We don't want to waste engineering's time, so we're piloting this with a
small number of groups so we can see if we're going in the right direction,
and stated what we expect to see happen with this work so we can decide if
we'll continue with it.

-- Emma Humphries

On Fri, Jan 29, 2016 at 4:17 PM, Richard Newman  wrote:

> Starting in the second quarter of this year, if you’ve taken on a
>> component, I’m expecting you or your team to look at the bugs which landed
>> in the component on a more frequent basis than a weekly triage.
>>
>
> In my experience, component watching adequately serves this purpose, and
> component watchers collaboratively respond to, immediately triage, or flag
> with a tracking-? flag. That might not be true for some components, but it
> is for the three products I watch.
>
>
>> Assigned to a developer, release tracking flags nominated, and set at
>> priority `P1`. If the bug is being worked on by somebody from outside your
>> core team, a team mentor should be assigned.
>>
>
> I think it's worth pointing out that it's not always worth assigning bugs
> to a developer — in my experience that does more harm than good if they're
> not working on it. Be realistic. Neither does P1 mean anything useful in
> many of the components I follow.
>
> Perhaps it would be worth taking a step back and explaining what problem
> you're trying to solve here, and why you think that problem is the one we
> should be solving?
>
> Again, speaking from my experience, re-triaging and re-processing the
> backlog within the context of current product priorities seems to be much
> more of a neglected task than processing the handful of new bugs that
> arrive each day — it's rare for a new bug to slip through the cracks in the
> Fennec component, but we have a long list of old bugs that we triaged,
> declared important, and never looked at again.
>
> You will have a really hard time trying to get buy-in on this process
> without demonstrating that there is significant benefit in the additional
> time investment.
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

PSA: Please stop revving UUIDs when changing XPIDL interface

[Ehsan Akhgari]

(Sending this in another thread in case people didn't see my note at the
end of the original thread.)

The new rules are in effect for mozilla-central and the repositories that
merge into it.  Revving UUIDs is no longer necessary.

Happy hacking!

-- 
Ehsan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Bug Program Next Steps

[Richard Newman]

>
> Starting in the second quarter of this year, if you’ve taken on a
> component, I’m expecting you or your team to look at the bugs which landed
> in the component on a more frequent basis than a weekly triage.
>

In my experience, component watching adequately serves this purpose, and
component watchers collaboratively respond to, immediately triage, or flag
with a tracking-? flag. That might not be true for some components, but it
is for the three products I watch.


> Assigned to a developer, release tracking flags nominated, and set at
> priority `P1`. If the bug is being worked on by somebody from outside your
> core team, a team mentor should be assigned.
>

I think it's worth pointing out that it's not always worth assigning bugs
to a developer — in my experience that does more harm than good if they're
not working on it. Be realistic. Neither does P1 mean anything useful in
many of the components I follow.

Perhaps it would be worth taking a step back and explaining what problem
you're trying to solve here, and why you think that problem is the one we
should be solving?

Again, speaking from my experience, re-triaging and re-processing the
backlog within the context of current product priorities seems to be much
more of a neglected task than processing the handful of new bugs that
arrive each day — it's rare for a new bug to slip through the cracks in the
Fennec component, but we have a long list of old bugs that we triaged,
declared important, and never looked at again.

You will have a really hard time trying to get buy-in on this process
without demonstrating that there is significant benefit in the additional
time investment.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Bug Program Next Steps

[Kyle Huey]

On Fri, Jan 29, 2016 at 3:45 PM, Emma Humphries  wrote:

> We believe that the number of outstanding, actionable bugs is the best
> metric of code quality available, and that how this number changes over
> time will be a strong indicator of the evolving quality of Firefox.
>

Why do we believe that?

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Bug Program Next Steps

[Gervase Markham]

On 30/01/16 00:45, Emma Humphries wrote:
> This is a terminal state for a NEW bug. We acknowledge the bug exists, it
> affects people, but it is not important enough to warrant working on it.
> The team will review and accept patches from the community for this bug
> report.

Without wanting to pile on, as I know others have concerns about other
parts of this plan, and without wanting to say it's only you doing this,
but: can we all please stop using the word "community", as this sentence
implies, as "people outside the paid 'team' who get to work on things
which are not important enough for the important people to spend their
time on"? Community is not the antonym of "team", nor is it the antonym
of "employee".

The original message was about the world we are working towards. In the
world I'm working towards, every team includes people we pay and people
we don't, on an equal basis, and we are all one community.

Thank you :-)

Gerv

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Does SSE2 usage still need to be conditional?

[Cameron Kaiser]

On 1/29/16 9:43 AM, Ashley Gullen wrote:

FWIW, the Steam Hardware Survey says 99.99% of users have SSE2 (under
"other settings"): http://store.steampowered.com/hwsurvey


For that to be valid, one must assume that the population of Firefox 
users and Steam users are sufficiently similar. I don't think that's 
necessarily true since most Steam titles have substantially higher 
system requirements.


Cameron Kaiser
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Does SSE2 usage still need to be conditional?

[Mike Hoye]

On 2016-01-29 2:05 PM, Cameron Kaiser wrote:

On 1/29/16 9:43 AM, Ashley Gullen wrote:

FWIW, the Steam Hardware Survey says 99.99% of users have SSE2 (under
"other settings"): http://store.steampowered.com/hwsurvey


For that to be valid, one must assume that the population of Firefox 
users and Steam users are sufficiently similar. I don't think that's 
necessarily true since most Steam titles have substantially higher 
system requirements.
While that's a fair point, Microsoft turned compiling with SSE2 on by 
default in Visual Studio in 2012, and it's been basically impossible to 
buy an x86 CPU without it since...  2004 or so?


I've tapped chutten about this, and he says:

14:33 < chutten> Easy as pie. ping["environment/system/cpu/extensions"] 
contains "SSE2"

14:33 < chutten> or, rather, the inverse

... which he then explained to me means "we can get our own data in 
short order."


He says it'll be straightforward to pull in, so he's going to do that.


- mhoye
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Does SSE2 usage still need to be conditional?

[Kartikaya Gupta]

I also want to highlight the thing at the end of the gist linked above
- the majority of the non-SSE2 population are on 43.0.4. That is,
they're keeping up-to-date, and would likely be affected by this more
than somebody stranded on an old version.

On Fri, Jan 29, 2016 at 3:29 PM, Chris H-C  wrote:
> tl;dr - Around 99.5% of Firefox Desktop clients on release channel
> represented by (a 20% sample of) pings submitted by on January 21, 2016 had
> "hasSSE2" detected.
>
> Here's the analysis and results on github. Please feel free to check my
> work: https://gist.github.com/chutten/4959c873d7fbbec0785a
>
> Keep in mind we cannot prove a negative from this. I cannot state that
> those pings without hasSSE2 correspond to clients that don't have SSE2
> support on their machines. So I tried (and failed, see bottom section of
> that gist) to keep analysis and discussion centred on the "hasSSE"
> population alone.
>
> :chutten
>
> On Fri, Jan 29, 2016 at 2:44 PM, Mike Hoye  wrote:
>
>> On 2016-01-29 2:05 PM, Cameron Kaiser wrote:
>>
>>> On 1/29/16 9:43 AM, Ashley Gullen wrote:
>>>
 FWIW, the Steam Hardware Survey says 99.99% of users have SSE2 (under
 "other settings"): http://store.steampowered.com/hwsurvey

>>>
>>> For that to be valid, one must assume that the population of Firefox
>>> users and Steam users are sufficiently similar. I don't think that's
>>> necessarily true since most Steam titles have substantially higher system
>>> requirements.
>>>
>> While that's a fair point, Microsoft turned compiling with SSE2 on by
>> default in Visual Studio in 2012, and it's been basically impossible to buy
>> an x86 CPU without it since...  2004 or so?
>>
>> I've tapped chutten about this, and he says:
>>
>> 14:33 < chutten> Easy as pie. ping["environment/system/cpu/extensions"]
>> contains "SSE2"
>> 14:33 < chutten> or, rather, the inverse
>>
>> ... which he then explained to me means "we can get our own data in short
>> order."
>>
>> He says it'll be straightforward to pull in, so he's going to do that.
>>
>>
>> - mhoye
>>
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Does SSE2 usage still need to be conditional?

[Chris H-C]

tl;dr - Around 99.5% of Firefox Desktop clients on release channel
represented by (a 20% sample of) pings submitted by on January 21, 2016 had
"hasSSE2" detected.

Here's the analysis and results on github. Please feel free to check my
work: https://gist.github.com/chutten/4959c873d7fbbec0785a

Keep in mind we cannot prove a negative from this. I cannot state that
those pings without hasSSE2 correspond to clients that don't have SSE2
support on their machines. So I tried (and failed, see bottom section of
that gist) to keep analysis and discussion centred on the "hasSSE"
population alone.

:chutten

On Fri, Jan 29, 2016 at 2:44 PM, Mike Hoye  wrote:

> On 2016-01-29 2:05 PM, Cameron Kaiser wrote:
>
>> On 1/29/16 9:43 AM, Ashley Gullen wrote:
>>
>>> FWIW, the Steam Hardware Survey says 99.99% of users have SSE2 (under
>>> "other settings"): http://store.steampowered.com/hwsurvey
>>>
>>
>> For that to be valid, one must assume that the population of Firefox
>> users and Steam users are sufficiently similar. I don't think that's
>> necessarily true since most Steam titles have substantially higher system
>> requirements.
>>
> While that's a fair point, Microsoft turned compiling with SSE2 on by
> default in Visual Studio in 2012, and it's been basically impossible to buy
> an x86 CPU without it since...  2004 or so?
>
> I've tapped chutten about this, and he says:
>
> 14:33 < chutten> Easy as pie. ping["environment/system/cpu/extensions"]
> contains "SSE2"
> 14:33 < chutten> or, rather, the inverse
>
> ... which he then explained to me means "we can get our own data in short
> order."
>
> He says it'll be straightforward to pull in, so he's going to do that.
>
>
> - mhoye
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Just Autoland It

[Steve Fink]

On 01/29/2016 08:37 AM, Mike Conley wrote:

Since making the review requester feel crappy is not generally
considered good, most review requestees don't push back on MozReview
requests, even if they find it very frustrating to work with.  I think
this dynamic is at the heart of a lot of the angst about MozReview:
people just feel put upon.

That's a good point. From my observations and interactions with the
MozReview team over the months, I believe a great deal of the initial
effort has been to lower the ramp for the requestors, as opposed to the
requestees. The fact that we're seeing so many review requests go
through MozReview might be a sign of success in terms of that work.

Anecdotal evidence, along with the sentiments in threads like this (and
elsewhere) suggests that it would now probably be worth shifting the
emphasis on lowering the ramp for the requestees.


Personally, I think the main issue is that people can't "get" the data 
model by looking at the interface, at least not until using it for quite 
a while. And that means that everyone is coming in with different 
notions of what's going on, and complaining about the things that are 
broken *in the context of what their misperceptions* of what is 
happening or should be happening. In short, many of the complaints are 
mistargeted, because people don't understand what the tool actually is. 
And saying "just file specific bugs" isn't always right, because many 
times the user wouldn't have run into the problem in the first place had 
they better understood what was going on.


A random example: the last time I used MR, I wanted to change the 
reviewer on one of the commits. But the reviewer wasn't editable, and I 
didn't know why. The whole list of commits and reviewers was right there 
on the page; why couldn't I edit them? What kind of authoritarian 
overopinionated thing is this, anyway, that doesn't let me change my 
reviewers after I initially select them? I made sure I was logged in, even.


The problem was that I was on the display for a particular commit 
(probably the commit for which I wanted to change the reviewer, I'd 
imagine.) The list of commits at the top is just a read-only summary of 
what you're working on, presumably there to help you stay oriented or 
something. It doesn't make a whole lot of sense for all of the *other* 
commits' reviewers to be editable when you're in a single-commit view. I 
mean, they could be. Or there could be a separate place in the UI where 
you could change the reviewer for the current commit. Or just that one 
commit's reviewer could be editable. I could file a bug requesting any 
of those.


But that's wrong. The underlying problem is that the interface does not 
convey the distinction between single-commit vs whole-review views. The 
right fix is to remove, collapse, or reformat the top summary section to 
deemphasize it and make it very very clear when you're looking at one 
commit vs the overall thing. I did not realize that until much later, 
when I was writing my earlier rant in this thread.


So, IMHO, you're going to get a lot of junk bugs with the current status 
quo -- as in, you could implement the requests and things would be 
incrementally better, but if the interface communicated what's going on 
better then the bug filer wouldn't have gotten stuck in the first place. 
Whatever workflow the filer was trying to follow might be slightly more 
streamlined, but the benefit is less than what could be accomplished if 
users were a little more on the same page [no pun intended].


I hope I'm not seen as beating on the MR team. Despite being a light 
user, I have communicated a bunch of feedback and found them to be 
responsive (and friendly). It helps that I find our current set of 
bugzilla-based workflows to be archaic and arcane, and for MR to be the 
right general structure for what would be better. But I'm going to 
repeat my toplevel beefs with MR as it stands:


- tab abuse (people get lost and confused)
- the data model is nonobvious and difficult to discover (people get 
lost and confused)
- needs to do better at facilitating communication between the author 
and the reviewers


I can file bugs for these, but they're not directly actionable. I could 
file actionable suggestions, but I would hope that people closer to MR 
and/or are more UX-y than me would be able to accomplish these goals 
better than I could[1].


Steve

[1] It turns out that I do have some UX background, but I suck at design 
and prefer to practice my whining skills.


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform