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 <gsz...@mozilla.com> >> 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 <e...@rtfm.com> wrote: >>>> >>>>> On Thu, Jan 28, 2016 at 8:25 AM, Honza Bambas <hbam...@mozilla.com> >>> 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 _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
