Monday, March 18, 2013

Converting blogger blog to github blog

Following my previous post on this I decided tghis weekend to see how it would look to have my blog  become a repo - and still maintain some of its blog-ness.
First I used the previous post summary to create a job in OD - humanscript-style (or better here)
to get someone to do the manual part of the conversion.
The job took me less than 30 mins to write up and post.

My filtering questions proved very successful in easily determining the qualified person.
The first two applicants ignored them - the first person that answered them was immediately hired.



The job followed the "standard humanscript" delivery model. Fork my repo do the job when done issue a pull request for me to verify. I had already created the basic structure of the repo and hand-edited two random posts myself to be used as examples. (that preparation took another half an hour)

Right after hiring I sent a standard warm welcoming email - the applicant told me that they would have everything done by Saturday night. Throughout the day Saturday I was checking my email to see for any update - so as I can reply immediately. Here is the thread of messages I exchanged.


The job was a complete success. 
You can see the resulting repository at http://github.com/ogt/otdump. (You will need to navigate through the year-> month-> leafs to see the individual blog posts. As part of the conversion all images were saved in github (I wasn't as consistent before - some images I used were saved in blogger some were referenced). 
As you can see from the messages I missed an important question that the contractor discovered.
 - how to map tag/label functionality that I have used (otdump.blogspot.com/search?q=helloworld
The contractor also didn't seem to understand my request for incremental delivery.

Meanwhile, right after I posted the first job, I posted a second one. I still needed a script that generates a "home page" - the readme of the repository. I decided to do this in two steps. A script that creates the "db" in the form of csv, and a script that creates the the home page (and probably more pages than that) from the csv.

Here is the job for that:


In this case the first Friday applicant responded with a decent answer to my question.
But the quality of the answer didn't make confident to proceed with the hire. I opted to wait overnight to get more candidates. Next morning I had 4 people that have responded, 3 total have answered the question, 1 of them said honestly that he didn't know the answer to one of the questions, two had answered correctly both questions, but one of them did a more thorough job reviewing his response (less typos etc).. so I chose him - who also happened to be the least expensive ($10 instead of $15 - I ended up paying him $15 in the end)
Here the candidates cover letters: (1 failed-one question, 2,3 ignored questions, 4 answered


And here is the cover letter of the person I hired


I proceeded in parallel with the first job post - and I ended up having the output by Sunday noon.

Here is the message thread I exchanged with the contractor.



Note that again the contractor was able to find problems I didn't spec correctly.
Note that I didn't have to provide any credentials - my message threads could very well have been public discussion.

In  both cases I went to github accepted the pull requests which were merged without any issue.
I forgot to say that I created a milestone associated with each job and pasted in the milestone the job post - so as I have the instruction associated with each pull request. (dglittle does this by asking the contractor to include the instructions in the commit - which is something that causes usually confusion)
I want to experiment a bit using github's actual functionality (milestones ) for that.
Interestingly milestone text gives the github flavored markdown which is better than OD.  So it may be that I only put a summary in the OD post and put the rest of my job post in github - they do have all the necessary API as well. I manually associated with each pull request the milestone so automatically when I merged the pull request the milestone closed!. It was neat.

There is one last thing to do now - the generation of the readme file.

No comments:

Post a Comment