Feedback on recent Patchwork update

Tue Mar 29 21:22:39 AEDT 2016

David Miller recently posted a comprehensive review [1] of the latest
version of Patchwork available on 'ozlabs.org' [2], and it's been a bit
of an eye opener*. This instance of Patchwork has gone from v0.9.0 to
v1.1.0, and the major version increase is mostly a reflection on the
scale of a UI changes that Patchwork has undergone. It seems to be
these UI changes, rather than the other non-visible changes in v1.1.0
[3], that have irked power users like David and (presumably) others.
Something needs to be done about this.

I've included a copy of David's original comments below, along with my
thoughts on how each item could be addressed. I'd love some feedback
on these so we can start addressing them. I think most of the issues
are solvable, and the last thing I can imagine doing is a blanket
revert.

In addition, it's also worth discussing how to get these upstream. I'm
really not happy backporting such far reaching changes to a supposedly
"stable" branch ('stable/1.1'), so I'm thinking the bulk of these
changes should end up forming a 'v1.2.0' release. This would mean
blocking Cover Letter and Series support for another week or two, but
I'm personally OK with this.

Finally, there needs to be some debate on how best to prevent this kind
of thing from happening. Patchwork caters to a lot of different users,
each with a different set of requirements (the Freedesktop instance
being a case in point). We need some way to announce intentions for
features like UI changes or dropping support for a Django version, etc.
before we do so. I don't know what this would look like, but I'm open
to suggestions.

Cheers,
Stephen

* Is this how the Gnome 3 team felt? :)

[1] https://plus.google.com/+DavidMiller/posts/EwRaCxDSiWW
[2] https://lists.ozlabs.org/pipermail/patchwork/2016-March/002488.html
[3] https://github.com/getpatchwork/patchwork/blob/master/CHANGELOG.md#110---2016-03-03

---

> A couple of complaints about the new patchwork installed this weekend
> on ozlabs.org, I think it's a lesson on what matters for high
> frequency workflows for maintainers.
> 
> 1) The "delegate" radio button now lists all patchwork users on the
> entire site, instead of just the users who are members of the
> project. So instead of having to choose between 2 or 3 developers
> for delegating a networking patch, I have to scroll through hundreds.
> This is unusable.

This was a feature that was requested both via the mailing list and,
funnily enough, from a member of the audience during a talk I gave
at FOSDEM this year. We've tried to keep things as uncluttered as
they can be through use of an auto-complete widget, though it's
clearly not good enough. I see two options here:

* Instead of displaying all users alphabetically, the list will display
  users who are maintainers first followed by all users.
* A user configuration option is added to determine what kind of
  delegation you want: all users, or just said project's maintainers.
  This can be configured from a user's profile.

> 2) Don't change the layout of the patch list pages with new fonts,
> new spacing, etc. when part of the usage is clicking a lot of check
> boxes. Now all of the boxes are spaced apart differently thus
> throwing off all the muscle memory heavy users of patchwork have been
> accumulating over the past decade of patchwork usage.
> 
> Nobody who uses this stuff a lot cares if the fonts or CSS layout
> layout is pretty, we just want to get as much work done as fast as we
> possibly can.  And any new layout like this works against that goal.
> 
> If you want to be able to change the page layout willy nilly like
> this, give me a way to drag select large numbers of patches side by
> side with a click and drag gesture or something like that.

I think the recently merged "shift-select" patch will help [4]. To
summarise, this lets you use the shift key to select a range of
patches and is, to me, a clear usability boost. As for the general
spacing, let's see if we can compress this further without reducing
readability. This could also be a user configuration option, a la
Gmail's cozy/compact UI setting.

> 3) Comments are now after the PATCH. This is nuts. That's the first
> thing I want to see after the commit message! I want to see if people
> have reservations or major feedback about the patch before I even
> see the patch itself.
> 
> Do people understand this? The comments and feedback are more
> important than the patch itself. For example, if the kbuild robot
> says ANYTHING about a patch, I'm marking it as needing changes. I
> don't need or want to invest the time reading the patch at all when
> this happens.  But now I have to spend time scrolling past it, this
> is bad.

Jeremy has resolved this, and the ozlabs instance is now updated
to reflect this. We could also add an counter on the patch list page
to state how many comments a patch has, if this would help?

> 4) The list of all projects used to fit on one single page on my
> screen, now it's pages and pages of scrolling. Don't change the
> layout if it fits less information on the screen. I'm happy to
> squint at a crappy 4 point font if it allows me to take in more
> information on the screen at once and scroll around less.

Agreed on this point. In addition, the page looks awful on mobile
(yes, some folks do use this on mobile). We can either make the
boxes smaller (6 per row, reduced height), or go back to a row
format but more in the style of the "Popular respositories"
window found on a GitHub profile page [5].

> If none of the above makes sense to anyone, try real hard to imagine
> what processing 500 patches in a single day might be like. It
> happens to me periodically.  More often an average day is 100 or so,
> and even at that rate the things happening above are deal breakers.
> Together they could make it take twice as much time or more to
> process incoming changes each day.

Totally understood. As I said, we're dealing with a lot of different
users with very different use cases. What matters for some users
doesn't necessarily matter for others. We're just trying to find a
balance.

[4] https://lists.ozlabs.org/pipermail/patchwork/2016-March/002458.html
[5] https://github.com/stephenfin