I think if we want to experiment in MozReview, we still need to reflect something in Bugzilla that kills the nuance and avoids unexpected landings from folks trying to be helpful. It's not hard or risky to add one additional flag (making review/feedback/land all available) and let MozReview do most of the experimentation with the workflow.
I've changed a ton of stuff in Bugzilla over the years, which is why I tacked on the low risk alternative. :) On Fri, Jan 22, 2016 at 2:12 AM, Gregory Szorc <g...@mozilla.com> wrote: > On Thu, Jan 21, 2016 at 10:37 PM, Mike Connor <mcon...@mozilla.com> wrote: > >> Like Greg, I'm a big fan of reviewer-lands-if-ready. It's a huge >> simplification of workflow, saves developers time, and lets machines do >> work instead of humans. That said, I don't think we should be surprising >> people or unilaterally imposing changes to their workflow. The best way to >> do this is to make it simple to adopt, and demonstrably better than the old >> way. Developers will migrate over time as they see the light. >> >> I think this is an easy fix if we're willing to modify our patch >> submission workflow to reflect a wider set of asks and responses. It's >> more or less the same mental model as the multi-state flags we use for >> tracking, there's more than one type of request, and more than one possible >> response. >> >> Simple proposal: replace review/feedback flags with a new, >> multiple-requestable flag. Possible values could be: >> >> feedback? >> review? >> land? >> feedback+ >> withcomments+ >> review+ >> land+ >> > >> >> Patch authors would be able to opt into the easier flow by setting >> "land?" instead of >> "review?" "review?" and "feedback?" would retain their current >> definitions. Patch reviewers would be able to respond explicitly with >> feedback, a conditional r+, full r+, or land+. >> >> * Anything where land+ is set would trigger autoland. >> * land+ should be set only if requested, or if the reviewer believes >> that's expected >> * patch authors would be allowed to autoland with review+ >> * withcomments+ or feedback+ would not allow autoland. >> >> In the short term, we could experiment with this as an additional patch >> flag (land?/+/-). I think the multi-state flag reflects current workflow >> reality and eliminates nuance, so should be explored. >> >> > We've already talked about changing the Bugzilla flags to better express > intent. The BMO gurus say it isn't something we should undertake lightly. > It's much easier to experiment on the commit message / MozReview side of > things while leaving the existing Bugzilla flags in place. e.g. we can have > MozReview convert "land?" in commit messages to "review? flags in Bugzilla > while having autoland convert "land?" into "r=" upon landing. > > It's worth noting that part of the reason we haven't enabled feedback flag > support and done more advanced things with commit messages is because > seemingly everyone practices slight variations of interactions with > Bugzilla flags and it's difficult codifying "One True Workflow" because > there are excellent justifications for nearly every variation. Code review > will continue to shift from Bugzilla centric to MozReview centric. And this > means that Bugzilla flags mean less and less over time. Perhaps we can > solve intent in MozReview without having to change anything in Bugzilla... > > >> On Fri, Jan 22, 2016 at 12:25 AM, Richard Newman <rnew...@mozilla.com> >> wrote: >> >>> Both of these behaviours are incompatible with reviewer-initiated >>>> landing. >>>> >>> >>> I've fallen on both sides of this particular fence; sometimes I want to >>> fire-and-forget a patch, and sometimes I still want to digest further after >>> getting review (or I know a piece of work is incomplete and further parts >>> will be forthcoming). >>> >>> Perhaps this needs an opt-in flag on the input side? >>> >>> "r?, and land it if you're happy" versus "r?, but I'll take care of >>> landing"? >>> >>> >>> _______________________________________________ >>> 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
