update

1 files changed, 10 insertions, 10 deletions

diff --git a/_posts/2011-03-06-how_to_use_github_effectively_for_your_project.textile b/_posts/2011-03-06-how_to_use_github_effectively_for_your_project.textile
index c990b3f..69aac11 100644
--- a/_posts/2011-03-06-how_to_use_github_effectively_for_your_project.textile
+++ b/_posts/2011-03-06-how_to_use_github_effectively_for_your_project.textile
@@ -4,13 +4,13 @@ title: how to use GitHub effectively for your project
 category: dancer
 ---
 
-<a href="https://github.com/">GitHub</a> provide an awesome set of tools for opensource developers. For <a href="http://perldancer.org">Dancer</a>, we try to use them as much as possible. I'll try to show and explain how we do our development.
+<a href="https://github.com/">GitHub</a> provide an awesome set of tools for opensource developers. For <a href="http://perldancer.org">Dancer</a>, we use them as much as possible. I'll show and explain how we do our development.
 
 <img style="display: block; margin-left: auto; margin-right: auto;" src="/static/imgs/github_dancer.jpg" />
 
 h2. code review
 
-<a href="https://github.com/sukria/dancer">Dancer</a>'s development goes fast. We try to ship often, we do a lot of refactoring, and we listen our users. This means processing pull request and issues as fast as possible.
+<a href="https://github.com/sukria/dancer">Dancer</a>'s development goes fast. We do our best to ship often, we do a lot of refactoring, and we listen our users. This means processing pull request and issues as fast as possible.
 
 h3. pull request
 
@@ -18,13 +18,13 @@ There is five developers with write access to the main repository. Each one is a
 
 When we're reviewing something, most of the time we pull the submited patches into a branch named *review/username*. If the reviewer is happy with the modifications, he will add a comment to the pull request: "approved" (and some other comments if it's required). In case he's not happy, he will comment *disaproved* and give his reasons (tests doesn't passes, or there is no tests for the patch provided, or this is not something we want, etc). If the PR is about something the developer doesn't really knows, or has a doubt, he skip this one, and ask for someone else to take a look.
 
-In order to merge the branch *review/username*, we need two developers to comment *approved*. Of course, for something simple, like a documentation fix, and changing a few line somewhere, we can merge this without requiring someelse to approve.
+In order to merge the branch *review/username*, we need two developers to comment *approved*. Of course, for something simple, like a documentation fix, or changing a few line somewhere, we can merge this without applying this process.
 
-As the work consist to only read the code, and comment, it's quiete easy to handle two/three pull request each day for a developper. When one of the developper with access to the repository has some time in the week, or during the weekend, he can go through the pull request, and merge the one marqued as approved, since he knows that the people who had already approved them understand the code.
+As the work consists to read the code and comment, it's quiete easy to handle two/three pull request each day for a developer. When one of the developper with access to the repository find some time, he can go through the pull request, and merge the one marqued as approved, since he knows that the people who had already approved them understand the code.
 
 h3. issues
 
-We don't use "RT":http://bestpractical.com/rt/ for our issues. It's not that RT is bad or anything else, it's just that GitHub's issues are more integrated with our workflow. GitHub's issues are really simple (one can even say naive), but most of the time it's ok for us. We don't need advanced features like "track how much time you've spend on this ticket" (even if I do track my time spent on Dancer, using "org-mode":http://orgmode.org/manual/Clocking-commands.html#Clocking-commands).
+We don't use "RT":http://bestpractical.com/rt/ to manage our issues. It's not that RT is bad or that we don't like it, it's just that GitHub's issues are more integrated with our workflow. GitHub's issues are really simple (one can even say naive), but most of the time it's ok for our usage. We don't need advanced features like "track how much time you've spend on this ticket" (even if I do track my time spent on Dancer, using "orgmode":http://orgmode.org/manual/Clocking-commands.html#Clocking-commands).
 
 One of the nice feature of GitHub's issues, is that you can close them with a commit. If the commit's message looks like 'closes GH-123', the issue 123 will be closed, with a link to the commit in the comment ("take a look":https://github.com/sukria/Dancer/issues/249). I find this feature really useful, since when refering to a closed issue, you can find the commit inside the ticket.
 
@@ -52,11 +52,11 @@ This is usefull when you want to have an overview of the work.
 
 h2. gitflow
 
-We're using "gitflow":https://github.com/nvie/gitflow to work. Gitflow is a nice tool that help you to create and merge branches. If you don't know gitflow, there is "a good article that explain the reason behind it":http://nvie.com/posts/a-successful-git-branching-model/.
+We're using "gitflow":https://github.com/nvie/gitflow to work. Gitflow is a nice tool that help you creating and merging branches. If you don't know gitflow, there is "a good article that explain the reasons behind it":http://nvie.com/posts/a-successful-git-branching-model/.
 
-Ok, this has nothing to do with GitHub, but I'll explain quickly what we do with this.
+Ok, this has nothing to do with GitHub, but I'll explain quickly what we do with it.
 
-Whe use the following convention:
+We use the following conventions:
 
  * master: only for release
  * devel: this is the development branch. This one should *always* work (tests can't be broken)
@@ -64,8 +64,8 @@ Whe use the following convention:
  * hotfix/$name: when we need to release a new version right now, without merging devel before, we create a hofrix branch
  * release/$version: when we're ready to ship, we create a new branch
 
-It's very rare that we need to push a hotfix or release branch to GitHub: thoses branches had a really a short life span. But *topic* branches can be pushed, when we want feedback from users or other developers.
+It's very rare that we need to push a hotfix or release branch to GitHub: thoses branches had a really short life span. But *topic* branches can be pushed, when we want feedback from users or other developers.
 
 h2. future
 
-We're already using "jitterbug":https://github.com/franckcuny/jitterbug to do some continuous integration. In a near future, we will use "git's notes":http://progit.org/2010/08/25/notes.html with jitterbug. The idea is to store inside a note, for each build, the duration of the build, and the result of the build (failure / success) and maybe the TAP output in case of failure. This will allow developpers to see directly in the log the status. Of course, GiHub already display them while browsing the logs, so this will be very useful.
+We're already using "jitterbug":https://github.com/franckcuny/jitterbug to do some continuous integration. When we push to GitHub, a payload is posted to jitterbug, and a build is triggered. In a near future, we will use "git's notes":http://progit.org/2010/08/25/notes.html with jitterbug. The idea is to store inside a note, for each build, the duration of the build, and the result of the build (failure / success) and maybe the TAP output in case of a failure. This will allow developers to see directly in the logs the status. Of course, GiHub already display them, so this will be very useful for all of us.