In this blog post I will try to show how the process of PR’ing for fixing an issue goes from the very inception to the final submission. Let’s take a look at the process for selecting it first.
Criteria. I found an issue that was two months old, nobody has commented on it, and it was labeled as pertaining to the Config component. The issue was created by @stof which meant he was doing some more important things and left this ticket to keep control of a minor situation so not to forget about it. I know he writes clear ideas and the text description was short, these were the main things that drove me to the ticket. I knew that whatever information was treating that if I read it many times I will be able to get every detail and complete details with the documentation or by reading the code. The title of the ticket was key as it conveyed that an existent class was actually needing to depend on another existent class within another component. So I thought it was about refactoring something that was more or less easy.
Context. I went into phpstorm and my setup as I have described it in the previous blog post series part I. And I went straight to the class and try to get acquainted of what it was doing. I knew this had to do with the command for dumping a configuration reference. I had used before but I knew little about how it was working behind. Then I got a little bit disappointed when I found a test for the dumper had been skipped and in reality very few people had noticed that this was somewhat broken. The test was a simple assertion compiling a sample configuration and then doing a the comparison of a given string to the output of the dump. The dumper was 204 lines of code (locs).
Fail. From the description and after spending sometime I realized several things after a spike attempt to fix the mismatch problems on the comparison. I realized that the description was not totally accurate on what it was needing, although good it was not exactly 100% what was to be done; I realized which use cases were already working and were supported, and which were the actual problem. I found other problems and assumptions that needed to be adapted to make our way into a solution. I took a look at the documentation here and there, identified doubts and problems, why it was not working in a certain way. Why even though the Escaper class had already been used we still had problems escaping some things, and what the configuration prototype documentation said about certain formats. The tests failed but I learned some more about the issue. In this process I ran composer on the component folder alone, ran tests, uncommented the marktestincomplete line and saw the test failing, then I ponder on whether I should write more tests or not or what kind of things would properly solve this issue.
Solution. All the failure was already enough, I could be able to comment some better description than the former on the issue in github, or I could ask a question back to seek a better direction, I was in a better position because I knew the problem. I did not have the solution but I understood the problem which is 90% or so of the solution. I also understood some history, who wrote it, how, the quality, strengths and weaknesses. After this and running phpunit over and over after solving smaller problems one by one I reached an all tests passing with green stage.
Finally I committed changes, push my branch to my fork, and did hub pull-request to create a pull request, then went in to add a description and that was it!
I think the most important part is to get a good grasp at the beginning, the faster you comprehend and reproduce the issue the better or faster it will be solved.
Encouragements in all good and remember to vote please cordoval for blogger at http://awards.symfony.com/community if you are liking this series 
