Working in big open-source projects can be challenging. Sometimes the code is hard to understand, nothing seems to move forward, and everybody is arguing. At other times, it can be deeply rewarding. Your issues are committed, the documentation makes sense, and everyone is happy. But it is seldom surprising.
Then last week, this happened:
Wow, right? Even though I knew in advance this would happen, it’s still a bit of a shock. Here’s a hint about how I feel: it’s complicated. Below I will reflect on the first week in this role and think about what lies ahead.
I really must set the stage with some context so you can understand what this week was like for me. I was really tired all last week at DrupalCon Dublin. I mean dog tired. I mean dead tired. I mean, I napped in public.
Incidentally: thank you @wunderkraut, you saved my life:
I know why. It is because I sleep like an idiot when crossing time zones. There will never be a time when I am proficient in dealing with jet lag. Over time I have decided that in situations like this it is best to push through and make the most of things. I must avoid microphones at all cost because when I am tired and am without a script I tend to talk nonsense. I may have done some of that. I am constantly brainstorming and I sometimes contradict myself on the way to an idea. That is why small group discussions are better for me. Fortunately, most of the first week was small meetings. Speaking of which, these are the meetings I attended:
- Future of PHPUnit and BrowserTestBase
- Entity Field API major issue triage
- Ideation part of Agile process
- Learning from Symfony about backward compatibility: with Nicolas Grekas of the Symfony core team sharing info
- Workflow initiative: I am so impressed with the work going on here
- Views major issue triage
And it was at these meetings that I started to get a feel for the requirements of being a core committer. It requires information parsing. There is a lot of reading, listening, and understanding to be done. It requires judgment. Your opinion is needed, and decisions are made. It requires trust. No one is the expert in everything. You must trust the contributors and maintainers.
All of these meetings were attended by super-smart and accomplished developers. It was awesome and overwhelming (see “tired” above). I tweeted the same:
I was honored to meet with some truly brilliant people @DrupalConEur. You know who you are!— cilefen (@cilefen) October 2, 2016
The next steps for me involve:
- Helping release 8.2.0.
- Becoming versed in the release cycle.
- Getting access to and executing analytics reports developed by the brilliant @xjm on the state of the core issue queue. Maybe I’ll find ways to extend them for new insights.
- Obtaining commit access.
See how “commit access” is the last thing listed? That is not an accident. As a release manager, the emphasis is on planning. I am comfortable to wait a little while before I commit code. Am I nervous about my first commit? Yes, I am. That’s a good thing.
If you have read this far, you probably care about this project at least as much as I do. It is a big responsibility. I want to do it right. Fortunately, there are policies and procedures regarding commits. Understand that I take these responsibilities seriously. With every action I take, I will be focusing on what benefits everyone in the Drupal community.
I almost forgot one more important next step:
- Think about long-term goals. That’s for a future article.