[Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

[Steven D'Aprano]

On Sun, Nov 30, 2014 at 02:56:22PM -0500, Donald Stufft wrote:

> As I mentioned in my other email, we’re already supporting two 
> different tools, and it’s a hope of mine to use this as a sort of 
> testbed to moving the other repositories as well.

If we go down this path, can we have some *concrete* and *objective* 
measures of success? If moving to git truly does improve things, then 
the move can be said to be a success. But if it makes no concrete 
difference, then we've wasted our time. In six months time, how will we 
know which it is?

Can we have some concrete and objective measures of what would count as 
success, and some Before and After measurements?

Just off the top of my head... if the number of documentation patches 
increases significiantly (say, by 30%) after six months, that's a sign 
the move was successful.

It's one thing to say that using hg is discouraging contributors, and 
that hg is much more popular. It's another thing to say that moving to 
git will *actually make a difference*. Maybe all the would-be 
contributors using git are too busy writing kernel patches for Linus or 
using Node.js and wouldn't be caught dead with Python :-)

With concrete and objective measures of success, you will have 
ammunition to suggest moving the rest of Python to git in a few years 
time. And without it, we'll also have good evidence that any further 
migration to git may be a waste of time and effort and we should focus 
our energy elsewhere rather than git vs hg holy wars.


[...]
> I also think it’s hard to look at a company like bitbucket, for 
> example, and say they are *better* than Github just because they 
> didn’t have a public and inflammatory event.

We can't judge companies on what they might be doing behind closed 
doors, only on what we can actually see of them. Anybody might be rotten 
bounders and cads in private, but how would we know? It's an imperfect 
world and we have imperfect knowledge but still have to make a decision 
as best we can.


> Attempting to reduce the cognitive burden for contributing and aligning ourselves
> with the most popular tools allows us to take advantage of the network effects
> of these tools popularity. This can be the difference between someone with limited
> amount of time being able to contribute or not, which can make real inroads towards
> making it easier for under privileged people to contribute much more than refusing
> to use a product of one group of people over another just because the other group
> hasn’t had a public and inflammatory event.

In other contexts, that could be a pretty awful excuse for inaction 
against the most aggregiously bad behaviour. "Sure, Acme Inc might have 
adulterated baby food with arsenic, but other companies might have done 
worse things that we haven't found out about. So we should keep buying 
Acme's products, because they're cheaper and that's good for the poor."

Not that I'm comparing GitHub's actions with poisoning babies. What 
GitHub did was much worse. *wink*


-- 
Steven