Time is up guys, time to start focusing on the hacking day.
My last notes about this go about the hanging out and getting to know symfony/symfony core better. So I have spent quite a bit amount of time meddling with the issues on github for the symfony/symfony repo. Here are some of the things I have noted:
Do your work, nevermind the rest: Whenever one submits a PR you will attract reviewers to your code. If changes are simple to do after some preliminary reviews then just do the work. If you receive a very strong criticism or is the wrong approach, just let it there and move onto something else, let it sit until it settles. Or it also can get settled by the major figures, repo maintainers, etc.
Surprises on level of support: Sometimes there will be issues on specific support of certain features. Remember to try to remain core. The core domain, the thing people will use the most. If it is a too edge case that only one person will ever use then you may not be investing your time wisely. And remember nobody is paying you for helping. Some components or pieces of software may not support a full specification for instance Yaml component. In this case in digging the issues you will find the reasons in a comment by the maintainer. This is very important as you are unveiling history and reasons why the project was lead to certain directions.
Be the change Try to participate and ask questions. Be careful you understand to the best of your ability the issue. But ask, is important to get clarifications to be able to work on failing tests or reproduction of the bug. Sometimes people will be lazy, they will just take forever to reply, or not be interested at all. Be different! Take things into your hands and submit PRs. By being the change you want there you will prompt other people to ask and constructively criticize certain decisions.
Never stop learning: Some things are hard, and that is a good thing, there is room to explore and feel a bit lost. Never stop learning details and open new doors. Yaml does not have a full spec implementation then check ruby implementation of yaml. Can’t it be ported? yes or no? why not? Learn to read and read, get familiar with the issues within the scope of a year or so or even more. Learn from the code of others. Don’t be afraid to ask.
Wait patiently and humbly: After all your PRs are submitted, keep calm, they will not necessarily be merged. It does not matter if they do. You are learning. If they are rejected is good because there is room to learn more and there is room to explore, why it is not merged. Also give time, the maintainer usually is very busy. Being a maintainer is a lifestyle, you know when and what you have to do, it is like being a ring bearer, is heavy. So just wait and relax, dive into other territories while waiting.
When a feature is requested please do not do thumbs up and leave: worst thing you can do is to spam others with just your desires. Please don’t do it, makes no sense. Same when you report a problem and do not even provide details on how to reproduce. Best is if you fork a Symfony Standard Edition exhibiting the problem. Never never please just do thumbs up and leave without pushing some code or details. You are not supporting, you are spamming. It is very different when the feature is complete and you do a thumbs up because you have reviewed it and yo have found no fault. So please stop spamming, we already receive a ton of email. No need for stupid thumbs up without review or code work. There is an exception for thumbs up which I think is valid, and is when you mount support to overcome a decision from the maintainer that is or seem to be somewhat political or unreasonable. Then it is about finding out how many people is really interested. That is different and needs to be pondered.
Please do review-oriented thumbs up with comments: PRs need your comments, thoughtful comments, and questions if you are contributing. You should contribute that way doing peer reviews. Thumbs up if you have the right reputation make a PR more trustworthy. The maintainer will be prone to merge it quicker. If you happen to be familiar with another related ticket that has not been tagged please link it in your comment. Is important to keep the issues interconnected so when they are closed there is little to search and easy to close related tickets operation is done seamlessly.
Make friends and pair program: While working on an issue please find opportunity to ask and befriend people. You need the right rubber ducks and helpers. I just pushed some hours ago an issue which i troubleshoot and was helped by another guy in UK. I wrote some code but ended up removing it and he found the fix after I have helped make setup for it to be found. It was a team effort, the change was small but significative. I couldn’t have done it alone and he couldn’t have found it out were it not for my testing code that put it to the surface concretely. I submitted the PR and I set the commit to his authorship. We are a team. So be friends and enjoy what you do.
All in all a hacking day is to put some greasy and start moving the pieces of the machinery. The faster you get the more excited you get the quicker reactions to problem the better. Come to the hacking day to learn the flow and to resolve problems.
Encouragements, your friend @cordoval
See you on the 14th! and i will be working from Warsaw, Lord willing, all this week on issues or my personal projects. Also I am looking for a decent job. /o/