A few things I've learned in the issue queue
“Big bang patches” are great -- at sprints
When I started working on contrib modules, I often identified a broad-sweeping issue with the module and then worked on it with a single issue and a big patch. These patches were often tens of kilobytes in size and changed a lot of the module.
This actually is more efficient in an admittedly limited number of circumstances. If you’re have a very busy schedule, the time it takes to break up large changes into smaller and smaller issues seems like a waste of time. “Well, I wouldn’t need to haggle over this temporary workaround if we just did it right!” It helps little that Drupal.org doesn’t have an easy way to make a parent issue with subtasks as does BitBucket.
Big bang patches also work well when everyone that needs to work on the thing is in the same room. This allows high-bandwidth communication that doesn’t need to go through the issue queue. You can iterate your code very quickly in that case, and the time to write a subtask like a complete and separate issue is a waste of valuable sprint time.
We need subtasks on Drupal.org
This suggests that, contrary to the issue standards on Drupal.org, we should have two issue templates. One template would be the full template we know now in Dreditor, the other would be a smaller subtask template:
Issue #123456
Title: Refactor the Pranic Lift for more 777
Body:Subtask of “Add obscure movie references to blog post” (link).
This is a workaround for D.O’s UI limitations. In the example above, the first line of the issue body references the parent (or Meta) issue. That way, a full description of the purpose and motive behind the change can be compartmentalized into the parent issue. Only a minimal description would be necessary.
“Nibble patches” are usually best everywhere else
Patches that focus on small changes -- or nibble away at the larger issues -- are usually best everywhere that’s not a sprint. Smaller patches are easier to write, easier to review, and easier to test. If a change does break things, it is easier to locate the specific commit when the changes are small.
Nibble patches also have another, subtle advantage that I didn’t appreciate before.
At my previous, no-Drupal job, I spent a lot of time in a very different headspace. I didn’t have the wherewithal to context switch from graphics and PowerPoint (which is not evil, bad slide decks are, blame the presenter and not the tool!) to code and web. After work, I’d block off a couple of hours in my evening to work on my modules. The time pressure was not unlike that of a sprint; I felt I needed to spend my time coding rather than writing issues for every little subtask.
When I started my current job I tried to maintain the same pattern, but it was draining. Going back to coding after coding all day no longer felt fun. Eventually, I decided to change my tactics. In addition to my normal 8 hour day, I also blocked off an hour before and after work to push my modules forward. This starts the day with something a bit fun to get my mind going. Throughout the day it’s easy to post a comment or reroll a patch since I’m already working with those tools. Often, it’s a welcome break when I’m stuck on another coding problem or waiting for something to build or boot.
Large patches take too long to mentally load. This requires a heavier mental context shift than if the patch were only a few dozen lines. Switching back to work then incurs an additional context shift. The bigger the shift, the more mental energy it takes, and the more exhausted you’ll be at the end of your day. It’s much less taxing to block time to make a meta issue and subtasks when you have a few hours to kill. Then execution can be done much more easily.
Nibble patches are better in the vast majority of circumstances, but that doesn’t make big bang patches “wrong”. They have a place, but that place is much more limited.
