Udacity的Machine Learning纳米学位课程中，关于Github的笔记。
听课范围：
Github Profile
Git 和 Github
Readme
Profile
Readme
Commit
Contribute to open source community
课程听了一半，笔记继续更新，有待排版。
show your work and how you work
照片
twiter，个人博客
recruiter最先看的是这里，看你有多活跃，几乎每天都会coding。
点进一个最popular的contribution的repository，可以看到scott做了最多的贡献，写了大部分代码。
页首加了get hub page for this library。
readme是repository里最重要的部分之一。
便于其他人阅读和使用代码。
comments里面可以加入版本的说明，feature增加的说明等。
hiring manager的职责 figure out what attributes do value in engineers。
第一要看的，就是活跃热图，看绿色的分布，看这个人是否热爱编程。是否经常做贡献，不需要总是在编程，但至少会有比较稳定的趋势。
接下来看这个人建立的repository，和他贡献过的repository。
挑一个最丰富的repo，花一个小时去读他们的code，从而看出他们是什么样的工程师。
也会看他是否在其它repo中有贡献，看他怎样和别人互动，协作，讨论。
写readme
便于自己记忆code，回头再看看你写过的代码，你是否还记得你当时是怎么想的吗，是否还记得你当时为什么做了这些决定吗，便于别人使用，便于别人协作。
看如何使用这个code，有没有example，如果没有好的document，别人就会转向其它更方便的library，如果非要读这样的code，就会花费很多时间，
https://github.com/thoughtbot/factory_girl
https://github.com/zkat/can.viewify
https://github.com/udacity/create-your-own-adventure
项目简介，Description
其它文档，Documentation
安装，Install
额外信息：Contribution，当你想让别人更方便地加入进来，或者Issue
License
看下面这个例子
https://github.com/github/ledbetter
readme需要提供给user足够的信息以便于up and running your code
题目
描述：一两句，清楚并且精准地描述项目的精髓
Installation, common Usage, known Bugs
readme的长短取决于你的项目，没有必须的要求，只需要提供给使用者必要的信息。
copyright和licensing information，或者link。
下面这个网站，可以学习如何选license。
http://choosealicense.com/
这里有关于license的指南，
https://github.com/blog/1530-choosing-an-open-source-license
这里可以告诉你为什么要选license，以及不选license的情况：
https://help.github.com/articles/open-source-licensing/
建立license很简单：
提供一下已经知道的bug，这样用户就不用发愁为什么他的code无法成功运行。
用markdown写readme，易读，而且排版容易。
Github，Stack Overflow，Slack，Reddit
Here's a link to the basic Markdown documentation. You can also check out the differences in GitHub flavored Markdown here.
github中常用markdown命令
加粗
Isn't today a wonderful day?
斜体
And in that moment I thought to myself: Did I turn off the stove?
代码
You should use the strong tag.
标题
This is an h2.
Working with .md
Files
Much like how your HTML files should be saved with a .html
extension, your Markdown files should be saved with a .md
extension.
Markdown itself can't be opened in the browser like an HTML document. If you want to preview your Markdown files, Dillinger is a great online resource for you to do so.
If you are using Sublime Text, there is a plugin you can download to let you preview Markdown files right on your computer. If you are using Atom text editor, Markdown preview is baked right into the program (in the 'Packages' menu).
Here's a link to the basic Markdown documentation. You can also check out the differences in GitHub flavored Markdown here.
To preview Markdown in the browser, try Dillinger.
什么那个不好用，下面这个好用
http://dillinger.io/
well formatted commit messages
让别人知道，为什么这里有这样的code，何时做了怎样的修改。
方便别人解读，使用，维护你的代码。
hiring manager会看这个人有多么地擅长沟通，传递。
Udacity上的例子
http://udacity.github.io/git-styleguide/
The first line is the subject.This should be a short description of what changed.should be 50 characters or less, with the first letter capitalized, and end without a period. At Udacity, we also include a short annotation about the type of the commit, if it is a bug fix, a feature, change to the documentation, etc.
The body is next, this is where you give a more detailed description of why you made the change. The body should typically have around 72 characters per line. This is to ensure that the message fits into a terminal window when using git on the command line. You’ll also need to make sure there is a blank line between the subject line and the body.
Some commits don’t require a body in the message. If you fix a typo for example, it’s okay to only have a subject line.
You can also include a footer, typically this will be used to indicate which issues or bugs the commit addresses.
This does come with an exception of course. If you are working on an open source project, be sure to follow the message format for that project. This will make the maintainers happy and increase the chance your pull request is accepted.
从你的代码里可以看出，你是否善于协作，喜欢帮助别人，并且热爱编码。
面试官是怎么样从你的github上看出你是个好的协作者的，在一个团队里是如何表现的。
看他们参与的repo里的issue，
是否在on po requests里评论，
看他们如何与其它工程师互动。
看他们是否有耐心对待刚进入这个社区的成员，
找找是否有internet relay chat关联于这个repo，
看log，看他们是否helpful，kind，patient。
作为hiring manager，你想向new programmer提些什么建议，关于他们在参加contribute to很大很复杂的开源项目中。
break the ice in a new project,
找文档看，readme，clone the project，try to build it, try to get it running, follow the steps in readme.
try to clarify some problems I have, submit a poll request with a few changes in the readme.
just move on to fix the bugs, and maybe actually contributing the features.
如何为开源项目做贡献
Github
https://guides.github.com/activities/contributing-to-open-source/
找一些最喜欢的开源的library，pandas：
https://docs.google.com/document/d/1ULcO23Edlydaf82zycRdSWHKUme5pmNnC4OoMefIZ-c/pub
python: pandas, numpy, scipy, seaborn, scikit-learn, orange, nltk
r: dplyr, ggplot come to mind
also 'stan' for r
pymc for python as well.
http://www.datakind.org/
http://databits.io/ for data and data vis related competitions
https://www.kaggle.com/ - Kaggle is a platform for data prediction competitions. Companies, organizations and researchers post their data and have it scrutinized by the world's best statisticians.
读documentation，不会的问题就create issue，寻求帮助。
创建issue，这个项目的，也可以是你自己的，
要nice，都是public的，
最好的contribution方式，就是improve the documentation。
check list
https://docs.google.com/document/d/1a9AKnNyqfGgdQV5ohPCN5H9ntnEUhMptWMwVBWURCN0/pub?embedded=true
GitHub Profile Checklist
Link to associated GitHub Profile Rubric
General
I’ve uploaded at least four projects to GitHub.
I’ve verified that my account shows knowledge about how to make incremental commits.
For the last two weeks, I’ve made and pushed some sort of commit, no matter how small, to repo(s) each day.
Personal Profile
I have a professional GitHub name. If at all possible this GitHub name is my own name.
I have a professional profile photo (recommended to be a photo of yourself, but could also be stylized).
My profile is up to date.
Profile includes at least one up-to-date links for: 'URL' and/or 'Company' fields and/or ‘Contact Email’ and current location.
Projects
I have starred at least one repository I’d like to keep track of.
My projects have meaningful names.
My projects have a completed README that says what the purpose of the project is, any instructions about how to use or view it, and what kind of collaboration is sought.
Not all forked repos/changes require modifications to the README, especially when contributing upstream to another's project (would need to be a substantial change). All changes should be documented with commit messages to explain the changes.
The last commit I made to a project matched the commit style guide I chose. If I did not follow the Udacity git commit style guide, then I have included a link to the guide I did use to show consistency.
career resource
http://career.udacity.com/resource-center/contributing_open_source.html
end