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