Becoming a Drupal Core Mentor

t's finally time to start doing something I should have done long ago: mentoring new core contributors! I've spent a small chunk of time as a mentee, setting up my own development environment (dev env), finding issues in the mentoring queue and on Drupal.org (d.o), and interacting with other core contributors. While writing documentation and doing rerolls has been a great way to learn Drupal, the real rewards have come from working with other contributors. It's been a great comfort to know that I can ask for help on IRC, and can always find a mentor online during the core mentoring office hours.

And the bonus is that teaching others is the best way (for me) to learn things! So I went to YesCT for some advice on where to start. Here are a few resources she pointed me to (in addition to this big page o' mentor resources):

First of all, the most important thing to remember for everyone in the Drupal community is that "we are all mentors." This blog post from YesCT is pretty much what I was trying to say in para #1, but she says it better. Being friendly is the best way to encourage new contributors to come back! See also: WebChick's comic about her first encounter on IRC with "the Drupal Community on a Bad Day."

Next we have a key component of being a mentor: reviewing new contributor's work. This requires knowing how to review the contributor's work, and how to review a patch itself (to check that it was done correctly). Sticking with the theme of constructive criticism, gentle reminders, helpful pointers and other supportive input here. Teaching contributors how to interact and communicate with others is a great way to keep everyone positive and engaged.

As a side project, I'd like to help update dm.o and d.o to merge issue task instructions with the regular issue queue, essentially add functionality to the d.o issue queue. Todo for me: read through these related core mentoring on d.o issues. I had just recently noted that having contributor task instructions linked on d.o as they are on dm.o would be much easier than googling them every time I start work on a new issue. Turns out there's an issue for that! (there's also a google doc I won't link to here, but, note to self...)

Then we've got resources for planning a sprint, which I'd really like to do at a Drupalcon in the near future, but am currently lacking a topic to sprint on. If anyone needs a sprint co-leader, I'm happy to help!

Part of sprinting of contributing is going to be getting everyone set up with a local environment to work with. At an event like Drupalcon, or even something on a smaller scale, this can become problematic if everyone is downloading new software etc at the same time. So here are the Drupal Community Tools Download Instructions (dctdi. Tech is almost as bad as gov't with the acronyms). We've also got an Austin specific Core Mentoring page here and of course the perennial dev env setup page here.

Phew. So far I've had a look at most of those pages, but I need to go back and read the issues for dm.o->d.o as well as go through the mentor resources links thoroughly. It's just really great to have a specific goal and project to work on! I enjoy contributing on issues, but with the current D8 beta push it's been hard to find anywhere I fit in lately. Tallyho.

An attempted re-roll and several more hurdles

ssignment the second! With the help of Git Tower to tidy up my git messes, it's time to try out a re-roll. Or at least, futzing around with a patch until it works. This one was assigned to me during the core mentoring office hours, which meant it was already rather late at night. I couldn't work on it for at least 10 hours, so inevitably someone else had a whack at it first. Not a problem, always good to get things done, and I kind of like the competitive aspect there.

However, the posted reroll failed the automated tests, and a subsequent comment indicated that a single element was missing from that reroll that had (presumably) been in the previous version. Hokay. So where does that leave me? If it's missing just one thing, that one thing can be inserted and then tested again, yes?

Problems: I need to make sure I'm testing accurately, refreshing my entire local repo every time. I need to figure out exactly what is missing and where it goes. Update patch file. Test again. Upload. That seems easy, right? It's the technical details of how to do all that correctly and the first time that I get hung up on and unsure about. I need a lot of practice.

1. Actually, on this one, I'm going to take a close, side-by-side look at the two versions of the patch and see if I can isolate the missing bits, drop them in, and call it a day. This should also clue me a little more regarding patch structure. I get the concept and the diff and the +/-, but parsing all that together on read through will take some practice. Doing this manually seems to have worked, my patch applies.
2. Also going to try doing it this way, per berdir on IRC: "one trick would be to apply the previous patch over the current one with --reject, then the file should be added but all other changes would conflict and you can ignore them" 

And said patch passed tests and was reviewed affirmatively, so I guess it's ok. Frankly I'm amazed that things don't get broken more and that so many contributors are also patient mentors. Or my sample from the IRC is skewed, but I'm definitely grateful for that patience. 

Or rather, I'll try that second option as soon as I seriously sort out how to get my branches to work. Seems like changes I make on a checked out branch are still affecting my local head? That doesn't seem quite right. And meanwhile, 8.x doesn't seem to be working with MAMP anymore and I think that's enough for one night. Really looking forward to getting more experienced with all this.