It is important to have some plan of work on a project because it allows having a kind of success metric and not relaxing too much. When we with my mentors began working, we set up a plan on the first month (spoiler: failed to follow it).
Week 1: The first look at ppx's and how they are useful for code coverage (build a toy ppx that register raised exceptions)
Week 2: discovery of the compiler build system (integrate this toy ppx in the compiler build system; make it build ocamlc and ocamlopt, and the testsuite; discover some exceptions that are never explored by the testsuite)
Week 3-4: vendor in bisect_ppx.
Week 4 milestone: upload this first coverage test result on the web.
The first-week task was completed fast enough, but further everything began to stretch endlessly. Now we are only working on the integration of bisect_ppx (3-4 weeks goal). I think this is so because I underestimated the complexity of tasks and a number of different sources that I should explore to make every little change in the code. And, for sure, I should have to pay more time and attention to details.
If we talk about the assessment of the complexity of tasks, I could mention one of the recent tasks that I solved: handling the dependencies in order to make the part of the instrument without using external tools. During the one of the live discussions I received the explanations of the parts that I struggled with and really thought that it was the last difficulties in this file, so told that I think it will be two days or less when I complete this part. Actually I spent about a week handling following parts of the file.
This taught me to give a more accurate estimate of time, since it is very likely that some unforeseen difficulties will arise.
Now we are going to complete integration of this instrument by the end of this week, share the report with community and start getting rid of the coarse parts of this implementation, creating more elegant and supported solutions for using code coverage.