phasmantistes

GitHub is not at the "bottom of the funnel". They're in the middle: people who work there today may go on to wildly successful careers elsewhere. And people who have bad experiences there may not.

So please don't make the pipeline argument. Just because other earlier stages have failed to be welcoming to minorities doesn't mean GitHub shouldn't try, and just because GitHub is a corporate employer doesn't mean their employees aren't still living developing human beings.

* Oracle sues Google on copyright grounds.

* Case is overseen by Judge Alsup, who taught himself Java in order to understand the technical merits of the case. Case is split into two phases: copyright and patents.

* A jury finds Google to be infringing on copyright, but deadlocks on the fair-use defense. The jury finds Google to be non-infringing on all patents.

* Judge Alsup breaks the jury's deadlock on copyright by ruling that APIs are not copyrightable in the first place.

* Oracle appeals the patent claim, Google simultaneously appeals the copyright claim (it wasn't 100% in their favor).

* The Federal Court of Appeals (9th Circuit) hears the case due to the patent portion. It overturns Alsup's decision, declaring that APIs are in fact copyrightable. It remands the case back down to Judge Alsup.

* Google petitions the Supreme Court to hear the case instead, but the Court declines the request.

* Judge Alsup oversees a second trial, this time solely on the fair-use merits.

* The jury finds that Google's use of the APIs indeed falls under fair use.

But it is hard. No browser has succeeded in serializing full tab state: dom, forms, js, pending requests, etc. Chromium has been working on it and has large pieces of it but it is very very hard to get even close to fully correct.

You're letting perfect be the enemy of better.

Code reviews mean that every time I want to integrate with master I've got to 'grab a lock' and schedule and wait for a code review.

You're using a terrible code review system. You should be able to have multiple potential commits out for review at any given time. You should also have multiple pending commits from your coworkers on your queue at any given time. The code review process is asyncrhonous: process them at your leisure (though sooner is better than later, for obvious reasons). Once the review has been approved, it can be rebased onto or merged into master. If the patches you're writing are so far-flung that they don't apply cleanly, break them into smaller pieces.

What typically happens in these code review cultures is you tend to make monolithic commits (to minimize the # of code reviews you have to do) and you also tend to minimize diffs with the code base (to make the CR easier for the reviewer).

These two statements are contradictory. Monolithic commits by definition increase the diff with the codebase, not decrease it. What you tend to see are meaningful commits: commits which do one specific thing, and fully test it, without breaking any other systems.

    >>> foo = A.b
    >>> bar = A.b
    >>> hex(id(foo))
    '0xdeadbeef'
    >>> hex(id(bar))
    '0xdecafcab'
    >>> foo is bar
    False

This database contains data from the Panama Papers and from what the ICIJ is calling the "Offshore Leaks", which is a conglomeration of the Offshore Secrets and other smaller leaks between then and now.

The two taken together hit a corner (heh) case and give rise to a bug.

Long story short, companies offer guaranteed set-size rewards as a counterpoint to the black market's potential highly variant payouts.

Sure you can. Just a couple paragraphs previously, you were making the point that cryonics is "just medicine", and medicine and (for example) agronomy advance at very different rates. I can easily imagine a future in which we have the technology and medicine to revive all of the frozen cancer patients, or all of the frozen ALS patients, but are still struggling with drought, climate change, and widespread poverty.

I was also disappointed that the discussion afterwards put so much emphasis on him as a person, and not on the actual math, but I don't hold that against the film itself. Movies about artists and authors have never been about their works of art either: the movies are about their lives, and I think it is appropriate for cinema to be used as a medium for biography rather than as a medium for education.

After the showing, there was a panel discussion with the director, composer, producer, two actors (Stephen Fry!), and three consulting mathematicians who helped the production. One of the topics that came up was the recent (finally!) interest in Hollywood for making movies about technical people. Since the dawn of cinema, we've made movies about artists, writers, and poets. But it is only recently that we've started making movies about scientists (Stephen Hawking) and mathematicians (Alan Turing).

In my opinion, this movie puts both The Theory of Everything and The Imitation Game to shame. It is much more moving and beautiful than both, and it doesn't fall into the either the trap of overly simplifying the math, nor of overly dramatizing his life. If you have any interest in math, science, or computer science (much of which is underpinned by his work in number theory), I highly encourage you to go see this film.

You can upload multiple different versions of a single code review, and reviewers can diff both against the base and against previous versions of the review. This is helpful for showing "stories", responses to comments, and for "my original commit got reverted, so here I've reuploaded it, and then also uploaded the fix, so you can clearly see what's different this time".

Unfortunately, that's not the 90% case that I see. Most of the time a multi-commit PR contains N-1 commits of incremental development and one final one that fixes all the tests and typos and removes debugging print statements. Neither the project nor the author benefit from having those intermediate commits integrated verbatim.

Using fast-forward without squash is also a bad idea in many cases: the string of commits may contain multiple points that don't actually build or pass tests, even if the final commit in the chain fixes all that. There's no point in landing those broken commits, and doing so will confuse bisection tools.

Fast-forward with squash, and enforcing reasonably sized code reviews as a matter of culture, is the best of all worlds in my opinion.

For example: I check out a repository, and create a local feature branch. I create a commit containing the tests for the new feature, then one for the first draft of the new feature, then two or three for bugfixes. Each commit is small, and self-contained, but importantly isn't standalone. If someone checked out the repository in the middle of my chain of commits, they wouldn't have a working product. Then I upload my change for code review. There's no point in reviewing each of my ~5 commits individually: they only make sense to the reviewer as a combined unit. And there's no point in landing them individually: they only make sense for the overall project history as a combined unit.

In a project with many developers (e.g. 1,000 like the Chromium project), every developer has different local practices. Some keep their work based on HEAD of master via rebase, others via merges. Some do test-driven development, some don't. Making the code review the atomic unit of work, rather than the messy string of local commits, helps the project enforce common etiquette, commit formatting, and readable history.

Recognizing that people may have problems, recognizing that the activity graph and streak metric may aggravate those problems, and then saying that the charts shouldn't be removed and the people should just deal with it themselves is not particularly empathetic.

Yep, some people have difficulty building boundaries between their work life and their non-work life, or between their coding life and their non-coding life. (Some people don't want to build those boundaries, and that's fine, but some people do want to build them and yet have a hard time doing so.)

But just because they have a hard time doing something other people find easy doesn't mean we shouldn't make it even easier.

Removing the graph or the streaks metric isn't "giving someone a fish". It is realizing that they have difficulty catching fish when they try, and giving them a net to make it easier.

But I think your second paragraph addresses the real problem: contributing 18hrs/weekday and contributing 5mins/day are both legitimate open source contribution styles. But the "streaks" metric removes all subtlety -- how many contributions are they actually making; are the changes meaty or trivial; do the changes break CI; do the changes address Issues in their respective repos -- and so I don't believe it is a helpful metric to display.

Personally, I believe it does more harm that good, by encouraging people to maintain streaks even if doing so actually decreases their true productivity or happiness. But no matter how much or how little harm it does, I think it is hard to argue that it does much good, since it is such a high-level distillation of complex information.