So I just got yet yet another
“you have a typo in your documentation”. While I do appreciate these kind
reminders, I think it might be a good exercise for those who want to try GIT
and Github pull
requests, which make
it possible for you to contribute to open source and fix obvious problems
with no questions being asked — just do it yourself, and send the changes
to the original author(s) through Github.
The official documentation for Github pull requests is a little bit verbose
for beginners. Basically what you need to do for simple tasks are:
- click the
Forkbutton and clone the repository in your own account;
- make the changes in your cloned version;
- push to your repository;
- click the
Pull Requestbutton to send a request to the original author;
For trivial changes, sometimes I accept them on my cell phone while I’m
still in bed. No extra communication is needed.
Occasionally I see reports of this kind of trivial documentation changes in
the R-devel mailing list, and I believe that is just horribly inefficient.
You could have done this quietly and quickly, and the developers could have
merged the changes with a single mouse click. (Oh, okay, well, you know,
SVN, mailing lists, …)
For the knitr repository, it has two
gh-pages. The R package lives in the
branch, and the knitr website lives in the
gh-pages branch. If you
want to fix any problems in the website, just check out the
git checkout gh-pages
All pages were written in Markdown, so edit them with your favorite text
editor. For example, as the above comment pointed out, I omitted a right
_posts/2012-02-24-sweave.md, and you just add it, save
the file, write a GIT commit message, push to your repository and send the
I know I can do this by myself in five seconds, and it takes me way more
time to write this blog post, but I just want everybody to know how people
with different skill levels can play their roles in software development.
Let’s see how many minutes it takes for the pull request to come after I
publish this blog post. Hurry!!