Re: IETF Git and GitHub tutorial

[Michael Richardson <[e-mail]>]

Sarah Banks <[e-mail]> wrote:
    > If we were all engineers writing code as a day job perhaps this would
    > be second nature (or we'd be motivated to not admit we didn't know and
    > we'd figure it out). But we're not all engineers, and git is
    > unfortunately a tool for engineers. It's not as approachable as it
    > seems some of us think it is. Thanks for supporting the effort; I do
    > hope documentation solves the problem :)

I am a strong proponent of design teams using git (and I've used git for ID
for a long long time, and CVS before that!!!!).  
I consider github just a way for people without public IP addresses to use
git.  Github issues are also useful for design teams, but unless you do the
issue full-lifecycle bi-directoinal integration with the mailing list, which
seems non-trivial for WG chairs to organize (I haven't gotten it working),
then it is hostile to the formation of consensus.

Given that we believe in running-code and then rough consensus, I remain
a bit skeptical about efforts to make it very easy for
non-running-code-writers to be major contributors to technical
specifications.  {Where my thinking breaks down is when it comes to
non-bits-on-the-wire protocols, such as policy documents} 

So, I care less about making it easy for reviewers to be able make
pull-requests.  I significantly prefer that non-design-team members bring
their issues to the mailing list, and that they "send text" that way.

I think that the web interface to github is significantly more complex to
deeply understand than the CLI interface; at least given a OSX or Linux on
the desktop, and an having gotten over how ssh keys work. (And I consider
learning about ssh-agent to be something every student should have learned
before they go on their first work placement, and any 15yr old who wants to
write code should already know today)

It is only users of that other desktop that seem to have all the problems.
So, after decades of abuse from the makers of that companies' desktop
("This web site is designed for browser X in 1024x768. Please click here
download ActiveX so that we can p0wn your computer") I feel very very very
little sympathy.

And as I said in this thread, I don't think that the web interface supports
the full editing cycle: fork/edit/pull-request/rebase.  Maybe github's new
masters will find a good UX fix this; but I'd rather that they deployed IPv6.

If I thought there was a full-cycle solution with a browser, I'd do a
screencast of the web interface tomorrow.   If someone would like me to do a
screencast of the CLI version, I would be happy to that this week. (I'm at RIPE79)


-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [