6-th straight success !! (6 hrs from post to pull request)!!
I am very very happy.
So here are the few data points.
1. boxchareditor has my complete todo list as issues https://github.com/ogt/boxchareditor/issues
2. I posted the very first issue as an OD job - accidentally to the wrong team.. the OD interface is really tricky sometimes particularly if there are many jobs/many teams.
oD job : Add enhancement in open source javascript project
3. As you can see by now I have concluded to fully separating the task at hand from the job post
Here is the template for the job post https://gist.github.com/ogt/55b25e064f729cb5799d
4. I have started running a header and footer in the issue - the header captures the status of the issue (
- Sourced @ oD for $40 - Waiting for developers
- Sourced @ oD for $40 - Job in progress
- Sourced @ oD for $40 - Job completed successfully
In all the cases this links to the OD job. The footer is the "Yaml - end - matter" - something structured that can be automatically used by a bot to read and know what job to post
5. The job was not perfect - but this was due to a pre-existing bug in my own code that only manifested when I added a new brush. The contractor shield his code from the bug but didn't fix it.
6. I got a github comment against the issue from a 2nd developer saying that he had done the job but the job became unavailable!
7. github preview tool is invaluable - http://htmlpreview.github.io/?.... when you want to test a self a forked html-based github repo.
Other learnings:
- When you have a new repository - you will need to pump up the price a bit to attract developers. The idea is that the investment for a new to the repo person is quite bigger than a person that has already done tasks for the repo.
- When you are a new user - you will probably need to pump the price even more - you/yourself is an unknown quantity (that already is the case in OD)
- A well taken care job post, well formatted polished - (and for that matter a well polished issue) makes people a) take notice, b) want to work on it c) act carefully to make sure that what they do is/appears polished
Next steps -
1. fix the bug in my code
2. Expand the test todo - hard to accept pull requests without a test suite... and post it.
----a day later and a bit more sober after having worked on the bug.---
The bug was easy to fix easy to spot. I would have been happier if the developer had fixed or if I had found it and asked him to fix. Testing...
The developer didn't update any text in the readme etc. I think thats justified - in retrospect I should have done a better job mentally thinking the HS instructions.
I am very very happy.
So here are the few data points.
1. boxchareditor has my complete todo list as issues https://github.com/ogt/boxchareditor/issues
2. I posted the very first issue as an OD job - accidentally to the wrong team.. the OD interface is really tricky sometimes particularly if there are many jobs/many teams.
oD job : Add enhancement in open source javascript project
3. As you can see by now I have concluded to fully separating the task at hand from the job post
Here is the template for the job post https://gist.github.com/ogt/55b25e064f729cb5799d
4. I have started running a header and footer in the issue - the header captures the status of the issue (
- Sourced @ oD for $40 - Waiting for developers
- Sourced @ oD for $40 - Job in progress
- Sourced @ oD for $40 - Job completed successfully
In all the cases this links to the OD job. The footer is the "Yaml - end - matter" - something structured that can be automatically used by a bot to read and know what job to post
5. The job was not perfect - but this was due to a pre-existing bug in my own code that only manifested when I added a new brush. The contractor shield his code from the bug but didn't fix it.
6. I got a github comment against the issue from a 2nd developer saying that he had done the job but the job became unavailable!
7. github preview tool is invaluable - http://htmlpreview.github.io/?.... when you want to test a self a forked html-based github repo.
Other learnings:
- When you have a new repository - you will need to pump up the price a bit to attract developers. The idea is that the investment for a new to the repo person is quite bigger than a person that has already done tasks for the repo.
- When you are a new user - you will probably need to pump the price even more - you/yourself is an unknown quantity (that already is the case in OD)
- A well taken care job post, well formatted polished - (and for that matter a well polished issue) makes people a) take notice, b) want to work on it c) act carefully to make sure that what they do is/appears polished
1. fix the bug in my code
2. Expand the test todo - hard to accept pull requests without a test suite... and post it.
----a day later and a bit more sober after having worked on the bug.---
The bug was easy to fix easy to spot. I would have been happier if the developer had fixed or if I had found it and asked him to fix. Testing...
The developer didn't update any text in the readme etc. I think thats justified - in retrospect I should have done a better job mentally thinking the HS instructions.
No comments:
Post a Comment