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.
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
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.
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 http://awards.symfony.com/community.
I have lived long enough to push straight to master on symfony core :). Probably few people have done it.
https://github.com/symfony/symfony/commit/bb73852c95a5761d7d562fbc959367383b029264. But it is not important. Some people also say things on tweeter:
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 😛