5 ms·

I guess you can get the hang of Gerrit, but i tried it out a couple of times (i occasionally do work on projects in the Wikimedia git repo) and is pretty eviden

by huskyr 6y ago

I guess you can get the hang of Gerrit, but i tried it out a couple of times (i occasionally do work on projects in the Wikimedia git repo) and is pretty evident that the interface is written by developers with little knowledge of user experience. Moving stuff to Gitlab will probably increase the number of volunteer contributions, at least i'm more interested in contributing more now.

q3k 6y ago
I really don't mind the Gerrit UX - it seems to be optimized for daily use by programmers, not for onboarding speed. That's a tradeoff I'm very much okay with.
- badrequest 6y ago
  You're okay with the tool being difficult to use because you already know how to use it.
  - q3k 6y ago
    I'm okay with it being slightly more difficult to get started with, in return for higher productivity in the long run, yes. Right now, after spending a similar amount of time both with GitHub PRs (and Gitlab MRs) and Gerrit, I still find Gerrit much easier and faster to use.
    - llimllib 6y ago
      I'm generally okay with that tradeoff too, but we tried it early on at our company and the juice was not worth the squeeze, at least in our case. Designers and even many developers found it essentially impossible to use and the developers who were reasonably comfortable with it spent way too much time assisting others in attempting to use it. (fwiw I found myself somewhere in the middle - I like the model and understood the ideas but also found it annoying to work with in practice)
      - dionian 6y ago
        Same. Cool idea in concept. Not something I have enough time to be interested in using heavily.
  - svrb 6y ago
    Software should be written for users, not non-users. You'd think this would be self-evident and yet here we are.
    - zimpenfish 6y ago
      How do you then convert a non-user into a user with the least friction?
      - Cthulhu_ 6y ago
        Force. I for one never looked at Gerrit and thought "I should push this at my employer". I'll probably never use it unless I'm forced to.
  - lawtalkinghuman 6y ago
    I'm okay with Vim being slightly harder to learn to use than VS Code. A tougher learning curve in exchange for more powerful tools can be a good tradeoff.
    - huskyr 6y ago
      I think this is a good comparison, and exactly shows the problem: Vim is only used by a minority of developers, the majority use some kind of graphical editor (like VS Code). That doesn't mean learning Vim isn't a good tradeoff, it's just not a good tradeoff for the majority of people.
  - parliament32 6y ago
    "Because it's hard" is a bad reason to shy away from something.
    - marcinzm 6y ago
      No it's not, you have limited time and devoting X hours to gain back X/10 hours worth of productivity gain in the future is a bad investment. Don't do something hard for the sake of doing it unless the gains out weigh the cost. https://xkcd.com/1205/ https://xkcd.com/1205/
  - kortilla 6y ago
    Difficult to learn != difficult to use.
    - noizejoy 6y ago
      I agree with you - for tools I use on a daily basis. However, since my interests vary considerably, and therefore I dabble with lots of different tools, the difficult-to-learn tools never get enough traction in my limited human memory to get me to the easy-to-use stage. If a community doesn't want to engage occasional users, it's probably fine (maybe even desirable) to have a higher barrier to entry to make daily use really fast. If a community benefits meaningfully from occasional users, a high learning barrier may not be a good thing.
  - dionian 6y ago
    I already know how to use it and I hate how proprietary it is, I have so many other problems on my plate than customizing my Git to work a certain way. I like using the off the shelf tools that work nicely with the normal git workflows using temporary branches for MRs. And a nice UI that anyone can use with minimal effort or training.
- 20after4 6y ago
  Gerrit is so off-putting to new users that many never get over the learning curve. At Wikimedia we want to be welcoming to new contributors. We also have to consider the on-boarding experience of new staff members, as well as the productivity of staff and long-time contributors. Gerrit satisfies some people who have used it for a long time but it is almost universally disliked by newcomers. When your users are volunteers, you can't force them to use Gerrit until they get used it it. If the experience is bad enough then they will choose to spend their time on something else instead.
  - shandor 6y ago
    Curious, did you think of moving also the repos and reviews to Phabricator, as I recall WMF using that for task management?
  - bawolff 6y ago
    I'm personally somewhat doubtful that that is really the aspect of the new dev experience at wikimedia that is actually turning off newbies.
- bawolff 6y ago
  Gerrit ux is full of bugs that get in the way of daily use (maybe improved over time). Things like overriding ctrl-f in the browser but then having the overriden search bar not work or not being able to effectively type inline comments on mobile. I dont really think the choices that they did make that work, are really any better in optimized daily use than intuitive choices would have been. (Yes probably much of this is fixed)
u801e 6y ago
> Moving stuff to Gitlab will probably increase the number of volunteer contributions, at least i'm more interested in contributing more now. Is there a project out there that originally used something like Gerrit, Phabricator, Reviewboard, or a mailing list that moved to Gitlab or Github where the number of contributions increased after the change?
delsarto 6y ago
The git-review [1] tool makes it trivial to interface with Gerrit (it's likely packaged for your distro, see [2]). I've found many people struggling with Gerrit don't know about it and it has made their life significantly easier. It handles all the magic of pushing to refs so that you never need to know about it. You drop a .gitreview in your project and then your work-flow is literally $ git checkout -b my-feature-branch $ emacs ... <edit edit edit> $ git add -i ... $ git commit $ git review read reviews, edit $ git add -i ... $ git commit --amend $ git review # push new change revisions You can download an upstream change to use locally with "git review -d 123456" [1] https://docs.openstack.org/infra/git-review/ https://docs.openstack.org/infra/git-review/ [2] https://www.mediawiki.org/wiki/Gerrit/git-review https://www.mediawiki.org/wiki/Gerrit/git-review
- bawolff 6y ago
  Honestly, i find git-review much more annoying than just memorizing `git push origin HEAD:refs/for/master` (if that's too much easy to create a normal alias) and the gerrit web interface gives you the command to download a specific changeset. Git-review tends to break in unclear ways and sometimes do things other than what i expect it to.

by huskyr 6y ago

q3k 6y ago

I really don't mind the Gerrit UX - it seems to be optimized for daily use by programmers, not for onboarding speed. That's a tradeoff I'm very much okay with.

badrequest 6y ago
You're okay with the tool being difficult to use because you already know how to use it.
- q3k 6y ago
  I'm okay with it being slightly more difficult to get started with, in return for higher productivity in the long run, yes. Right now, after spending a similar amount of time both with GitHub PRs (and Gitlab MRs) and Gerrit, I still find Gerrit much easier and faster to use.
  - llimllib 6y ago
    I'm generally okay with that tradeoff too, but we tried it early on at our company and the juice was not worth the squeeze, at least in our case. Designers and even many developers found it essentially impossible to use and the developers who were reasonably comfortable with it spent way too much time assisting others in attempting to use it. (fwiw I found myself somewhere in the middle - I like the model and understood the ideas but also found it annoying to work with in practice)
    - dionian 6y ago
      Same. Cool idea in concept. Not something I have enough time to be interested in using heavily.
- svrb 6y ago
  Software should be written for users, not non-users. You'd think this would be self-evident and yet here we are.
  - zimpenfish 6y ago
    How do you then convert a non-user into a user with the least friction?
    - Cthulhu_ 6y ago
      Force. I for one never looked at Gerrit and thought "I should push this at my employer". I'll probably never use it unless I'm forced to.
- lawtalkinghuman 6y ago
  I'm okay with Vim being slightly harder to learn to use than VS Code. A tougher learning curve in exchange for more powerful tools can be a good tradeoff.
  - huskyr 6y ago
    I think this is a good comparison, and exactly shows the problem: Vim is only used by a minority of developers, the majority use some kind of graphical editor (like VS Code). That doesn't mean learning Vim isn't a good tradeoff, it's just not a good tradeoff for the majority of people.
- parliament32 6y ago
  "Because it's hard" is a bad reason to shy away from something.
  - marcinzm 6y ago
    No it's not, you have limited time and devoting X hours to gain back X/10 hours worth of productivity gain in the future is a bad investment. Don't do something hard for the sake of doing it unless the gains out weigh the cost. https://xkcd.com/1205/ https://xkcd.com/1205/
- kortilla 6y ago
  Difficult to learn != difficult to use.
  - noizejoy 6y ago
    I agree with you - for tools I use on a daily basis. However, since my interests vary considerably, and therefore I dabble with lots of different tools, the difficult-to-learn tools never get enough traction in my limited human memory to get me to the easy-to-use stage. If a community doesn't want to engage occasional users, it's probably fine (maybe even desirable) to have a higher barrier to entry to make daily use really fast. If a community benefits meaningfully from occasional users, a high learning barrier may not be a good thing.
- dionian 6y ago
  I already know how to use it and I hate how proprietary it is, I have so many other problems on my plate than customizing my Git to work a certain way. I like using the off the shelf tools that work nicely with the normal git workflows using temporary branches for MRs. And a nice UI that anyone can use with minimal effort or training.
20after4 6y ago
Gerrit is so off-putting to new users that many never get over the learning curve. At Wikimedia we want to be welcoming to new contributors. We also have to consider the on-boarding experience of new staff members, as well as the productivity of staff and long-time contributors. Gerrit satisfies some people who have used it for a long time but it is almost universally disliked by newcomers. When your users are volunteers, you can't force them to use Gerrit until they get used it it. If the experience is bad enough then they will choose to spend their time on something else instead.
- shandor 6y ago
  Curious, did you think of moving also the repos and reviews to Phabricator, as I recall WMF using that for task management?
- bawolff 6y ago
  I'm personally somewhat doubtful that that is really the aspect of the new dev experience at wikimedia that is actually turning off newbies.
bawolff 6y ago
Gerrit ux is full of bugs that get in the way of daily use (maybe improved over time). Things like overriding ctrl-f in the browser but then having the overriden search bar not work or not being able to effectively type inline comments on mobile. I dont really think the choices that they did make that work, are really any better in optimized daily use than intuitive choices would have been. (Yes probably much of this is fixed)

u801e 6y ago

> Moving stuff to Gitlab will probably increase the number of volunteer contributions, at least i'm more interested in contributing more now. Is there a project out there that originally used something like Gerrit, Phabricator, Reviewboard, or a mailing list that moved to Gitlab or Github where the number of contributions increased after the change?

delsarto 6y ago

The git-review [1] tool makes it trivial to interface with Gerrit (it's likely packaged for your distro, see [2]). I've found many people struggling with Gerrit don't know about it and it has made their life significantly easier. It handles all the magic of pushing to refs so that you never need to know about it. You drop a .gitreview in your project and then your work-flow is literally $ git checkout -b my-feature-branch $ emacs ... <edit edit edit> $ git add -i ... $ git commit $ git review read reviews, edit $ git add -i ... $ git commit --amend $ git review # push new change revisions You can download an upstream change to use locally with "git review -d 123456" [1] https://docs.openstack.org/infra/git-review/ https://docs.openstack.org/infra/git-review/ [2] https://www.mediawiki.org/wiki/Gerrit/git-review https://www.mediawiki.org/wiki/Gerrit/git-review

bawolff 6y ago
Honestly, i find git-review much more annoying than just memorizing `git push origin HEAD:refs/for/master` (if that's too much easy to create a normal alias) and the gerrit web interface gives you the command to download a specific changeset. Git-review tends to break in unclear ways and sometimes do things other than what i expect it to.