Stream: general

Topic: contribution friction


centril (Mar 17 2019 at 13:42, on Zulip):

@davidtwco Now I am curious... what would you rank highest on that list?

davidtwco (Mar 17 2019 at 13:47, on Zulip):

Hmm... now I need to make up a list. Probably build times, that took the longest for me to get used to when I started.

There were other things I recall like when I added my first test and would get the annotations incorrect (// ~ instead of //~) and there'd be no indication that was what was wrong.

I'm not sure though, I guess I went into contributing expecting there to be friction as I got used to how things were done - things like rebasing I've always just thought of as the price you pay for using Git. I tend to think that if someone goes into contributing to anything with an expectation of a frictionless process, they're going to end up frustrated, there's always something.

centril (Mar 17 2019 at 14:04, on Zulip):

oh yeah, those two are definitely up there

Jake Goulding (Mar 17 2019 at 14:10, on Zulip):

For maximum frictionless contributing, the author of the patch could send it into an email list (or post via a web form) and then an expert could just fix all the nits, grammar, etc for them.

davidtwco (Mar 17 2019 at 14:11, on Zulip):

I don't think that's frictionless (for everyone), it just shifts the friction entirely onto the experts.

oli (Mar 17 2019 at 14:23, on Zulip):

For maximum frictionless contributing, the author of the patch could send it into an email list (or post via a web form) and then an expert could just fix all the nits, grammar, etc for them.

Just for the record, such a contribution system would have meant I would not be a rustc contributor today. I literally have no idea how to contribute in such a way and it scares me to even think about it. There are reasons I never upstreamed my llvm experiments

centril (Mar 17 2019 at 14:39, on Zulip):

Yeah that's more of a linux kernel vibe than I care to go through; not my idea of frictionless.

Jake Goulding (Mar 17 2019 at 14:41, on Zulip):

@oli how could you not "know" how to do it? It's literally paste code into a webform and someone else does it for you. Zero burden on the contributor.

Jake Goulding (Mar 17 2019 at 14:42, on Zulip):

If you could type the code, can copy & paste, and can click thee submit button, you are good to go.

Jake Goulding (Mar 17 2019 at 14:44, on Zulip):

@davidtwco I agree. Is the assertion that changing from rebasing to merging results in a net negative reduction of friction across every participant? The code author, the reviewer(s), the people that look at the git history, etc.

Jake Goulding (Mar 17 2019 at 14:46, on Zulip):

Personally, I'm ok with requiring a basic proficiency in git and GitHub, but I also already meet those requirements so I'm not unbiased.

centril (Mar 17 2019 at 14:50, on Zulip):

I don't consider dealing with rebasing and submodules to be basic git proficiency

oli (Mar 17 2019 at 14:50, on Zulip):

@Jake Goulding Do you know how much of a burden it is to me to fill out a trivial form? I have a document on my desk that I got mailed via a phyiscal letter telling me to send an email to an address on it to make an appointment with my company's health check system. I have not touched it since more than a month

oli (Mar 17 2019 at 14:50, on Zulip):

I just want to do the stuff, not have 3 steps in between

oli (Mar 17 2019 at 14:51, on Zulip):

copy paste is literally the thing I never want to see anywhere. If I can't automate it down to a single command, it's not worth doing more than once a year

Jake Goulding (Mar 17 2019 at 14:52, on Zulip):

@oli The process I'm describing is less work than a current PR, really. You already submit a form to open the PR.

centril (Mar 17 2019 at 14:52, on Zulip):

@Jake Goulding maybe if the form was an IDE?

oli (Mar 17 2019 at 14:53, on Zulip):

@Jake Goulding Yea, I click on the link in the command line and get the form prefilled and press "Open Pull Request"

Jake Goulding (Mar 17 2019 at 14:53, on Zulip):

Anyway, to be clear (as I'm worried this isn't coming through), I don't think such a solution is a good one. It's just simply attempting to maximize the ease of contributing (evidently for the majority of people and not @oli)

oli (Mar 17 2019 at 14:54, on Zulip):

Filling in an explanation or a "fixes #123592349823" is not a problem, but not even necessary

centril (Mar 17 2019 at 14:54, on Zulip):

@Jake Goulding In none of the git-101 sessions I helped teach at uni was rebasing even a subject ^^

Jake Goulding (Mar 17 2019 at 14:54, on Zulip):

@centril I'd personally file that as an issue with the sessions, but again, I have bias

davidtwco (Mar 17 2019 at 14:55, on Zulip):

oli how could you not "know" how to do it? It's literally paste code into a webform and someone else does it for you. Zero burden on the contributor.

There's a perceived friction vs actual friction difference at play too. If I think making a contribution will be hard ("wait, so I need to email my patches to somewhere? what format should they be in? how do I get them in that format? what address do I email? does the subject matter?") then even if the process is really trivial, I won't find out.

davidtwco I agree. Is the assertion that changing from rebasing to merging results in a net negative reduction of friction across every participant? The code author, the reviewer(s), the people that look at the git history, etc.

I personally don't find rebasing all that much more challenging than merging. It can just take longer. What you had suggested, having a form that you fill out and then experts do everything, reduces the friction (to some extent) on the side of the person filling the form, but that friction still exists - the person who's at the other end still needs to handle rebasing and all that - you're just putting all the friction on the lap of the experts.

As I see it, the not-rocket-science rule is a good rule and that in order to do it, a patch needs to be able to be merged cleanly by a bot into master - therefore when it can't be merged cleanly, a rebase needs to happen. I think having the author perform that rebase amortizes the pain of rebasing over the most people, which is desirable.

Jake Goulding (Mar 17 2019 at 14:55, on Zulip):

"here's a technique that is prevalent in industry, but we aren't going to teach you about it"

centril (Mar 17 2019 at 14:55, on Zulip):

@Jake Goulding not really, it's more a "and we only had time to go through this"

centril (Mar 17 2019 at 14:55, on Zulip):

i.e. the things that are more basic

Jake Goulding (Mar 17 2019 at 14:57, on Zulip):

Regardless, there is a middle ground. If contributors are incapable of rebasing, have someone do it for them. I've done it for rust-lang/rust once or twice when someone botched something.

Jake Goulding (Mar 17 2019 at 14:59, on Zulip):

Yes, introducing steps can reduce the absolute number of contributions; I believe that. I'm not always sure that a reduced number of contributions is a loss in the end though. This may be my elitism showing through.

oli (Mar 17 2019 at 14:59, on Zulip):

Fixing a botched rebase for someone is perfectly fine, but expecting all rebasing to happen on the reviewer side would slow down reviewing even more

Jake Goulding (Mar 17 2019 at 15:01, on Zulip):

Oh, I certainly agree. Again, I'm putting out options on how to make it possible to get more contributions coming in, which seemed to be the thrust of the original comments.

davidtwco (Mar 17 2019 at 15:01, on Zulip):

For me, the most interesting part of this discussion is trying to understand why rebasing is a friction point. I understand that it isn't always trivial but it's a necessary part of what we do, just as necessary as writing the code itself (which is way more complicated), so I've never really got why there's an aversion to learning and getting experience with rebasing, while there isn't with learning and getting experience with a codebase.

Jake Goulding (Mar 17 2019 at 15:03, on Zulip):

an aversion to learning and getting experience with rebasing

Especially considering that rebasing is a technique that applies across code bases and languages (although only in git and not other VCS)

Jake Goulding (Mar 17 2019 at 15:04, on Zulip):

why rebasing is a friction point

Also how/why is it more friction compared to merging?

centril (Mar 17 2019 at 15:07, on Zulip):

I think merging is more familiar; most of the pain I think involves having go back edit history + force pushing things as opposed to merge commits

centril (Mar 17 2019 at 15:07, on Zulip):

Pain can be acceptable but it should have a justification, that's all

davidtwco (Mar 17 2019 at 15:07, on Zulip):

The best example I can think of is a test failure - if a test fails, I need to learn why that failed, there was probably a good reason, so I'll just knuckle down and get on with that. If I need to rebase, then there's a good reason for it (be that "version control is worth it" or "they go by the not-rocket-science principle"), so I just knuckle down and get on with that too. I don't understand why the reaction isn't the same for some people (that isn't to say they're wrong, I just don't have experience with it).

centril (Mar 17 2019 at 15:08, on Zulip):

@davidtwco I'm not in their heads so I cannot really answer that ^^, it's just something I've seen

Last update: Nov 20 2019 at 12:40UTC