Symfony Hacking Day Toolset Series: Part IV

What is needed as for tools in a hacking day you would ask? or how to do it?

Travis: Travis is your friend because for instance in helping reproducing an issue under a Symfony Standard (SE) distribution, you can enable travis, or actually @fabpot just enabled it tonight, so now you can reproduce and write a functional failing test on SE that will reflect. Then do a Pull-Request (PR) to your own master branch on your fork from your own topic branch on your fork. This is to show just the changes you did without bothering people on the main repository. Then link the symfony/symfony issue repo on the description of your own PR.

weaverryan/spreadsheet Ryan Weaver has lead previous documentation hacking days very successfully! And it is no surprise we are reusing his methodology this time in our hacking day next week in Warsaw. So here is an example of the spreadsheet.

Screenshot 2013-12-05 02.49.12

What we need to learn here is. We have a link on the left column to the issue on github. Then we have the subject which basically is the component to which this issue is related. Then we have a description which we should reread as many times as possible. This could be different from what is in github and it could contain key information for a digested and easier tackling of the issue. Then comes the level, better pay attention to that one. I encourage you to always start with the easier and make your way up as you go. After, not in the picture,
there are notes and working on this column. If you take a ticket is because you are on it! Never put your name when you will not be working on it right the moment. Make sure you work on one thing at a time.
So this is what we will use, the tickets are ordered by priority, that meaning you should start from top to bottom. There are also several sheets for different repos, but I do advise you strongly to stick with a team and learn there before jumping between spread sheets.

Some tips while navigating github issues: At first we should skip the PRs which are mixed in the listing with the issues. Focus on issues, not PRs, we would review PRs but it is not the time. Make sure you click on every issue in your sight and read the description and decide whether is actionable for you or not. You at least now know what is it about even if you will not be solving it. You could still comment if you think you know something but better not. Keep focusing on finding the weak link issue. Once you skim over several of the issues, keep the spreadsheet open to only skim over those issues. You will waste valuable time if you just go there to familiarize yourself. The spreadsheet should be a safe place in which you can say this ticket is worth it and has been somewhat digested for me to work on.

These are some more tips:

  • avoid features because usually they are hard
  • bugs are usually hard but they are totally actionable
  • avoid hasPR labeled issues, they have been looked at by someone else
  • somewhat avoid milestone issues if you are a newcomer
  • tackle first the least commented and older ones with no comments or a small number of them
  • find and work on issues where the person has posed some level of laziness and do the work

Screenshot 2013-12-05 02.59.19

dbu/dashboard: One tool besides having a proper setup (oh by the way, I hope on hacking day everybody has installed PHPStorm EPA minimum, you can bring sublime2text or other lesser but you will be on your own, you better be a master, else you are bringing trouble and delays to the table. I am not going to even fuss my opinion, my opinion is strong on getting IDE problems out of the way, if you don’t use PHPStorm then you use something better, but never less, please!). So continuing 🙂 one tool i have found to manage number of issues is dbu/dashboard. It is under development but hopefully we will showcase it on hacking day.

Screenshot 2013-12-05 03.11.48

We will talk about more tools later on. Now it is really time to work. I do encourage you to start working on things on github ASAP. Especially if you are going to join an advanced group for the first time, please do your best to warm up, go to their repos and start tackling and working with their sandboxes and etc.

Time is up folks, Warsaw is here around the corner, flights and landings will take too much time to be communicated with quality from now on.

If you have not voted on awards please go there now, if you like this blog you should vote cordoval for blogger at

I have lived long enough to push straight to master on symfony core :). Probably few people have done it. But it is not important. Some people also say things on tweeter:

Screenshot 2013-12-05 03.21.54

But is not about me. I am really wretched person.
I thank the Lord for his Grace and favor, this is undeserved and enjoyable work I like to do. Hope you all benefit and pardon my incendiary tweets sometimes :). I am totally not fit, but hey there is grace.

your friend @cordoval

PS> remember to make it viral retweeting with the button below 😛

Get Ready for Symfony Hacking Day Series: Part III

I am letting it go some tips I wrote for the hacking day that can help you getting warmed up.

Screenshot 2013-12-03 22.10.58
Hacking day is going to be an opportunity to push work from repositories like FriendsOfSymfony, Symfony-CMF, Silex, Composer, Doctrine, Documentation, to even teaching community how to Contribute. This Hacking Day is going to rock!

If you haven’t participated in the early probing please do so now from the above link:

We encourage you after having checked any interest above for a particular repo, to jump onto github and start getting acquainted with:
– how github issues/pull-requests work
– issues labeled as easy-picks, some-component-name, some-release-milestone, etc
– issues descriptions and priorities
– issues that are not confirmed bugs or have no tests
– issues blocked for years and issues recently posted

Help reproduce: Work on reproducing the observed issue with a clean Symfony Standard (SE) installation pushed to your fork of SE. If it has failing test exhibiting the issue created by you would be outstanding.

Help clarifying: This is to help establishing proper descriptions and to have a very clear understanding of the problem. Some tickets created are support tickets and are easy to solve or should be referenced to be treated via the mailing list.

Help escalate and relate issues: If you see a bug that is not yet reported as such somewhere then please create it and notify in the description that needs attention because you think is serious. Sometimes issues are related or duplicated, because they are so many you can help us identifying and verifying that the issue has duplicated tickets, link them or import the information to the earlier reported so we can close the one is duplicated.

Start easy: If you are on the tab of issues or the list already sorted for you always start from the easy end and work your way up. If someone has taken the issue then skip it, if it cannot be reproduced after an attempt then move up to the next, if it is challenging then pair up and clear that is worth working on it; there is always that weakness in an issue that you can start from. Ask @fabpot, @stof or someone knowledgeable and they will point the possible options or plans for attack. We will try to have digested plans of attack for the hacking day so this can be ready for you to work or pair up and accomplish.

Focus on one thing: Tickets can be large or have short scope, always take the smallest unit of work and focus, make assumptions and leave out complexity asap, you want to solve the issue, not the issues, plural. Clean up code and submit about solving one thing only.

Let the review team review: We may have a team to review CS and clean code on PRs submitted. Do not worry about the beauty of your code, it will be reviewed, but rather work out the PR such that it has all comments or details to be further improved, any assumption or tests not written or half written. Leave it easy for the reviewers with a good description so that it can be properly reviewed. Then jump to another issue.

Time does not matter as much: Don’t care too much about time, more important is to understand things and exit the doors with a very clear understanding how to contribute to the repositories. If you do then you will have more time later on to do so. The thing is to lower the contribution barrier. To lower it means more active repositories, more bugs solved, more interesting ideas implemented, more security fixes, higher quality of code, more eyes more reviewers, more support, and more features.

Stick to your team: Most likely you will learn a lot and get to know one or more top devs within your team. Follow their lead, learn more about the repo, help support it, help contributing and gain experience, not only will be good for your resume, but it will be a friendship the whole community will appreciate. A long term contributor is well known by the repo members. It is a special feeling :).

Help others: If you see someone struggling then help the person, everybody around you is supposed to do the same thing with you or with anybody.

This is your chance, don’t miss it! Whether you are remote or local, we can learn a lot that day!

Encouragements in all good,

your friend @cordoval

Get Ready for Symfony Hacking Day Series: Part II

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.

Screenshot 2013-12-02 02.39.31

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 if you are liking this series 🙂

Screenshot 2013-12-02 03.00.08