One of the signature events of every Drupalcon (IMHO) is contribution day, when community members from around the world gather to work together in the same physical space to advance various aspects of the project - from strategic and community initiatives to contributed modules and themes as well as non-code contributions like Promote Drupal and, of course, core contributions.
As part of this, space is always set aside for new contributors, with community volunteers helping to organize, train, and mentor community members new to project contribution. This space strives to be a welcoming environment to those of all skills and skill levels, and includes a "First time contributor workshop" to introduce new contributors to contribution areas and tools.
tl;dr The team I mentored managed to complete the core issue we selected and get it committed to core by the end of the day - something that hasn't happened at a Drupalcon in several years!
Setting a goal
This year, I volunteered to be a mentor in the Mentored Contribution room. Some mentors are provided with a free ticket to Drupalcon, with the understanding that they will not only volunteer a full-day of their time during contribution day, but will also dedicate several additional hours of their Drupalcon experience to attending a mentor orientation, helping out at the Community Mentoring table (graciously provided by Kuoni in the main expo area,) among other tasks.
I've mentored at community events previously (DrupalEasy also provides mentoring services for hire,) so going into the day, I knew exactly what the goals for my "team" were going to be:
- Find a core issue that was clear enough for our team to be able to make a strong attempt to get it to a "Reviewed & tested by the community" (RTBC) status by the end of the day - with a stretch goal of having it committed to core before the end of the day.
- Learn to work with Drupal.org issue forks.
- Utilize DrupalPod (thank you, Ofer!) for all work on the issue.
It is important to note that not all tasks at Mentored Contribution are code and/or project related. The mentoring team does a great job of mentoring other forms of contributions as well.
Finding the right core issue
Having some previous experience, I knew that the first task would likely be time-consuming, so I took it upon myself to spend a couple of hours prior to contribution day to browse through Drupal core issues tagged "Novice" . Finding the right issue to work on during a contribution day is always tricky. Newer core issues tend to be very dynamic with active contributors working on them. Older core issues tend to be more difficult for various reasons - sometimes consensus isn't reached, other times the issue is too complex to be approached by a group in a single day. Prior to the Mentored Contribution day, organizers perform issue triage to narrow down potential issues.
I eventually settled on an issue from November, 2020 titled Add autocomplete attributes on login form and password reset form. The task involved adding some HTML attributes to a couple of core forms to help password managers more reliably target username and password fields. There was an existing merge request (MR) for the issue, but it was without tests (and about two years old.)
This issue seemed to have the criteria I was looking for - something approachable and a relatively straight-forward end goal, something that would allow us to utilize merge requests, and something that required some, but not too much, coding so we had a chance at finishing before the end of the day.
The team
Generally, mentors declare the types of tasks they'd like to work on, then volunteer greeters welcome folks as they show up for the day and bring them to a table to get to work once the "First time contributor workshop" is complete.
Our team consisted of eager new contributors, including: guzmanb, maxime.rffd, hexaki, samuel_orhan, rauch, guiu.rocafort.ferrer, mullzk, and binnythomas.
Using DrupalPod
The mentoring organizers recommend that we use DrupalPod during contribution day. DrupalPod is a browser extension and a set of scripts that make it super-easy to spin up a core development environment on GitPod. DrupalPod utilizes DDEV (something I know a little bit about) and runs completely in a browser, making it very convenient for contribution events like this.
We took some time to ensure everyone was able to spin up their DrupalPod environment for the existing MR, but quickly faced some challenges, as the DrupalPod environment was not launching cleanly.
We worked together to eventually determine that the main issue was the fact that the issue fork was over 2 years old and didn't have an 11.x branch, so the DrupalPod scripts were unable to properly set up the development environment. This allowed our team to learn about diagnosing and correcting issue fork challenges.
This also allowed our team to learn about (and practice) the necessary configuration and workflow for pushing commits from a Gitpod environment back to drupal.org. This involved setting up a temporary .ssh key set (with assistance from DrupalPod) and using Visual Studio Code's Git UI for making pushes (and not the command line.)
These tasks took several hours to complete - ensuring that all team members were staying engaged.
The issue code
Once we had the development environment and issue fork configured properly, it was time to discuss our approach to completing the issue. Several of our team members had to leave after lunch, so we were left with a core group of individuals, with new contributor guiu.rocafort.ferrer volunteering to take the lead. We planned out the change (and actually expanded the scope of the issue a tiny bit) and I received some guidance from an experienced core developer on what would be a reasonable PhpUnit test for this issue that I relayed back to the team.
I provided some guidance to the team to figure out where the test code should go (a new test class wasn't necessary; we just had to figure out the best existing test class to add to) and an overview of what the (relatively simple) test should look like.
At that point, I felt the existing team members had things well-in-hand, so I stepped back and let them get to work.
Getting to RTBC
By now, it was mid-afternoon and I was very hopeful that we'd at least be able to get the issue to "Needs review" with an outside chance of "RTBC." While the team worked on the code, I recruited a couple of experienced code contributors to review the code as soon as it was ready.
The team had some minor questions as they proceeded, but no blockers. They were all experienced PHP developers, so for them, this was the easiest part of the task, I suspect.
When they felt they had completed the task, I did a line-by-line code review with them, suggesting several minor changes, before they committed and pushed to the MR. I then alerted our reviewers (jurgenhass and lostcarpark) and they both agreed that it looked good. While this was going on, I alerted the mentoring organizers that we would potentially have a core issue at RTBC.
Live Drupal core commit
As long as I've been a part of the Drupal community, during Drupalcon contribution days, "live core commits" have always been a thing. From what I've been told, there hasn't been one for "several years" for various reasons, so I was quite proud of our team when nod_ showed up to congratulate our team and commit their changes to Drupal core on the big screen at the front of the mentored contribution room.
Retrospective
Looking back at the event, the only thing I would have changed is something that was completely out of my control - the fact that over half of our team wasn't able to stay for the full day and get the sense of pride that the rest of the team clearly had watching a Drupal core committer accept their contribution.
Personally, core mentoring is incredibly rewarding, and I always get more out of it than I expect. Along the way, I learned some additional details about DrupalPod as well as the pitfalls (and solutions) when working with old issue forks.
If you're an experienced Drupal developer, I encourage you to make a commitment to dedicate your time to helping to grow the next wave of contributors. If you're interested, say hello in the #mentoring-team channel of the Drupal Slack workspace.
Photos courtesy of Andy Blum.