pear philosophy

[salarkhan]

@supertopher here's my 2-member solution. Everything is def cleaner, but I think we should have a philosophical discussion about whether pear should support trios or not.

Outlined the strategy for x-member solution in #28. I'll try and implement it this weekend so we have solutions to choose from

[quackingduck]

@alyct is adding N user support to set-git-user: https://github.com/Devbootcamp/set-git-user/pull/16/files#diff-c0d56ab36850f07f336fe78ca04e294a

But for pear I think you guys should stick to just pairs as your taking advantage of the fact that git commits have two fields for names.

Really curious to hear what @mikelikesbikes and @mattbaker think about this because I know both of them didn't like how set-git-user doesn't use an email address that's associated with any github accounts

[mattbaker]

I think git-pear is cool if you want to have rotating authorship, and I had fun reading the code, but the idea of rotating authorship is not something I would use.

Rotating authors on commits makes it look like a single person was responsible for some unit of work. If I'm pairing, there's no concept of "I did this" and "she did that", it's always "we did this". So sharing authorship in a pair by alternating commit authors isn't valuable to me.

As for set-git-user, I think it does the best job it can given the constraints, and I don't see a better solution w.r.t to the email address so I can't complain. My concerns with the tool were alleviated by the adjustment we made in how we store multiple pair users, specifically the [github] custom data section in the gitconfig.

[salarkhan]

@quackingduck, I ended up with a solution to N users that wasn't as ugly as I thought it'd be. (#45) Will confer with @supertopher to see which route we take.

@mattbaker, huge huge huge thanks for looking through ze code. Here's my beef with your points: If rotating authors makes it look like one person did it, constructing a third author from the pair makes it seem like nobody did it.

• There's no reference to that imaginary third person on Github, which means I can't @mention the individuals of the pair in a conversation easily.
• If your goal is to show that 2 people were involved in a unit of work, git pear achieves that goal. It simply has the added benefit of providing references and creating history. I don't see how the following is any less valuable than a commit by mattbaker-quackingduck@devbootcamp.com
• There is value in Github's green squares, especially for DBC students. ( A result of the author of a commit being an actual Github user. ) As a student, it was motivating to see a visual representation of the work I put in. As a recent graduate, a couple recruiters contacted me simply because they saw how active my Github was. As a growing person, it's funny to click on commits throughout the year and laugh at all my shitty code & commit messages.

Again, thanks for looking through this code, guys. Really appreciate it.

[mattbaker]

Keep in mind that I was just sharing how I felt about it as a tool I might use personally, not commenting on git-pear's objective value. I think this tool is a cool way to deal with pairing and integrating with Github. For me, using this vs something like a shared authorship line has more to do with what's valuable to you, and I think you and I value different things. Which is sweet, because now we have tools that scratch both itches :thumbsup:.

If rotating authors makes it look like one person did it, constructing a third author from the pair makes it seem like nobody did it.

set-git-user generates a commit author name of the format "User A & User B", which could just as easily be their usernames instead of their full names if you want easier @-mentions. I think it does a good job of showing who's working together:

If your goal is to show that 2 people were involved in a unit of work, git pear achieves that goal. It simply has the added benefit of providing references and creating history. I don't see how the following is any less valuable than a commit by mattbaker-quackingduck@devbootcamp.com

It depends on how you define "unit of work". To me a "unit of work" is a single commit in git. A shared authorship line explicitly represents the concept of "user 1 and user 2 both made this". git-pear does indeed show that two people are working together, but the "pairing" part is implied based on the observation that commit authorship is ping-ponging over time. If I'm looking at at group project I'd personally like to see commits of the form "Did Stuff | Matt & Salar", "Tested Stuff | Mike & Myles" than discrete commits from all four of those users in rotation (how can I tell who's working with who?).

To me "pairing" has something to do with locality. "We're both staring at this code together" vs "we're both working on this from separate places and different times." I (personally) want the commit history to represent co-authorship, not merely coordination. If I see two authors in a commit stream, how do I know they're pairing vs. collaborating on a project independently of one and other?

I feel like git-pear is trying to solve the problem of co-authorship on Github vs co-authorship in git. I think this is a legitimate pursuit, it's just different from "how do we represent co-authorship in git".

Let's ignore Github for a moment — if we're just using git then I think set-git-user gets the job done. The author line is clearly updated to reflect both authors on each commit. I like that it does this, and I think it makes sense, though the email bit is a shame. To me, a shared authorship line is the best way to demonstrate that a commit was authored by two people, but it does not integrate well with Github.

git-pear ensures that Github can play nicer with your repo's commit history. I think git-pear is a great approach to communicate pairing while being under the constraint of Github integration, and I'm glad you're working on it. However I do think it does it at the expense of clarity since I can't tell the difference between two people collaborating separately and two people pairing. Abstractly, I think the idea of "a pair made this" is less clearly represented with git-pear.

It's just a matter of what's more important to you. I've favored set-git-user so far because I don't personally see a lot of value in the green boxes. I interviewed a lot of people last year, and I never paid attention to a candidate's activity graph, it just wasn't relevant to us (some people's best work never makes it to GitHub). However I respect that some people like yourself want their work on Github to be properly tracked in a pairing situation, and I think this tool achieves that goal well.

Man, that got long, I must have passed -v.

[salarkhan]

Ok so I was going to quote parts of your response and comment of em, but the entire thing was pretty eye-opening. I'm just going to quote the part that blew my mind the most:

I feel like git-pear is trying to solve the problem of co-authorship on Github vs co-authorship in git. I think this is a legitimate pursuit, it's just different from "how do we represent co-authorship in git".

I'm glad I'm getting a chance to converse about the philosophy of a project for once, instead of the technical details of how/why it works. This is really cool.

Anyways, I thought of a couple modifications to that can help git-pear do a better job of representing the that "a pear made this" on git, but I'm going to sleep on them to make sure they aren't crazy. Also because I haven't slept in way too long.

[mattbaker]

Looking forward to it dude! I hope you're sleeping right now! I love philosophical discussions around tech projects too, and I rarely emerge thinking the same thing I did entering them (best kind of learning IMO :)).

[mattbaker]

Also, we've moved away from the subject of this specific PR so we can take up the conversation over email or elsewhere if you want, I just want to be respectful of not de-railing your pull request.

[salarkhan]

Okay, so I slept on it, and this is what I came up with:

Representing "a pear made this"

• Currently, the committer/author name is simply Pear. That space could be used to show what pair was a part of that commit. Still not as clear as set-git-user, but it at least allows that information to be accessible.
• Edit the commit message -- ie. prepend or append the author & committer to every commit message. ( Not really a huge fan of this one )

....And that's about it. As to the PR, I don't really care! I'll rename the PR to Philosophy, and presto--we're un-derailed. @supertopher is getting back from vacay tomorrow, so hopefully he'll be able to weigh in on this too.

I interviewed a lot of people last year, and I never paid attention to a candidate's activity graph, it just wasn't relevant to us (some people's best work never makes it to GitHub).

This doesn't surprise me. A senior dev interviewing other seniors devs doesn't need an activity graph to validate the interviewee. However, I maintain that a junior dev with no jobs/references/etc to speak of stands to gain a fair bit from green squares.

[mattbaker]

This doesn't surprise me. A senior dev interviewing other seniors devs doesn't need an activity graph to validate the interviewee. However, I maintain that a junior dev with no jobs/references/etc to speak of stands to gain a fair bit from green squares.

I'll find some time to think about the rest of your comment, but for the record a solid 50% of our candidates were junior devs, if not more. Many of them were coming out of DBC or similar bootcamp programs.

[salarkhan]

Ah, but as an instructor for a bootcamp, you have a bias that many others in the industry do not.

That is, you are more keyed-in to what junior devs (esp. those out of bootcamps) are capable of.

This likely had an effect on how comfortable you were with interviewing candidates with little experience. Maybe not, but I'm sure it couldn't of hurt their chances :)

[mattbaker]

I've been an instructor since February 2014, prior to that I was an engineer at Wealthfront. I interviewed around 200 candidates last year, long before I knew anything about bootcamps :) That's sort of my whole point, I was trying to offer a perspective outside of DBC where Github activity wasn't that big a deal. I'm not saying other companies don't value it, just that the importance of Github activity isn't a truism.

[salarkhan]

Well...shit. Ok, I haven't interviewed 200 people so I suppose I'll have to stand down...for now hehehe

[quackingduck]

Awesome discussion. Some quick thoughts:

It just occurred to me that we could the notes functionality built into git to add our own meta-data to each commit. It could look like:

Co-Author: Myles Byrne <myles@devbootcamp.com>
Co-Author: Matt Baker <mattbaker@devbootcamp.com>

Then the author field in the commit could be like:

Author: Multiple Authors <see@notes>

And then if you had some way to market the tool like crazy see@notes would become such a popular author on GitHub it could motivate them to parse the notes for co-authors and give you those green squares :)

Regarding GitHub activity: this isn't a big deal for me either. Though I always go through a candidates profile and look at the quality of their commits and pull requests. To me it doesn't matter much if they haven't committed any open source in the past 6 months.

[supertopher]

in my test this doesn't appear to be working as intended. it looks to me like we are cycling the author and committer back to the same place. Though i'm in bed still and haven't done that much leg work on debugging

this config yields asimplechris as the author over and over

[mikelikesbikes]

@salarkhan Can you close this? I'm doing some Github cleanup, and this appears in my default "Pull Requests - Mentioned" view. It's also quite stale. :)

[salarkhan]

done :)

and whew, what a blast from the past