We recently went with some colleagues to the Drupal devdays in Cluj-Napoca, Romania, for 5 days.
Drupal has many events all over the world, but the devdays is the place to dive into the developer community and gain hands-on experience.
For some colleagues it was the first time they had been at Drupal devdays and we will not soon forget this! We have learned a lot and what we remember the most, you can read here.
On the devdays there are many sessions by people from the Drupal community, known or not. But we have mainly focused on contributing to Drupal.
Contributing to an open source code means that in your spare time, or as we do during our working hours, you contribute to issues from the Drupal issue queues.
Every contribution we make helps Drupal and its ecosystem to grow again. Even if it's just a typo from the documentation. The most important thing is that you just dare to do it! Dare to upload patches, tell what you think, what your process is and where you might want to go.
Keep it simple. Sometimes the solution to an issue is so big that instead of one monumental patch you divide everything into intermediate steps. Each intermediate step is a new comment with a patch. In this way, everyone working on the issue can follow your steps and it is once so clear.
Throughout the 4 days we spent in the sprint-room, there was something that stuck out head and shoulders, namely testing. Every issue, every patch that has an impact on both contrib and core Drupal must be supported by automatic testing. Sometimes the tests in a patch are many times larger than the actual modification. However, these tests give a certain certainty and guarantee that other mechanisms are not suddenly broken and that everything will continue to bolt.
The test infrastructure of Drupal.org is quite impressive. Every patch you add is automatically picked up and tested. You get (relatively) fast feedback on your patch, test results, coding standard conflicts, etc. Relatively fast means that you obviously have to wait a while for your results. In the case of a patch against Drupal Core this means that approximately 26,500(!) tests will be run. If the test is blunt, it clocks to one hour before all tests. A patch against a contrib module is obviously a lot faster because fewer tests need to be run. But the amount and lead time depends entirely on the tests for that module.
It is important to keep in mind when writing tests that you are not writing tests that succeed, but are just looking for things that can fail. For example, when writing tests you may encounter certain inconsistencies. Or you may even go a step further and write a test that fails because another known bug has yet to be fixed. As long as that test fails, you know that the other bug is still there. Here is an example. Wim Leers (Drupal Core Comitter) confirms that a test has failed due to a bug from another ticket. And this is deliberately left in. As soon as the test succeeds, we know that the other issue is fixed.
At the end is the most important lesson we have learned: If you want to contribute, just do it! No matter how small your contribution is. It really does make a difference, especially compared to doing nothing.
On the 5 days I spent in the sprint room, we made a difference, proportionally speaking, with small contributions. The Entity Embed module got a Release Candidate 2!
