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