Never Wait

Preface: This post is specif­i­cally about Pull Requests for Harper. Read the con­trib­u­tor guide­lines for a pro­ject be­fore open­ing a PR.

I get it. Open­ing a pull re­quest is an in­tim­i­dat­ing propo­si­tion.

It is non-triv­ial to put your blood, sweat, and (let’s be hon­est) tears into code and put that onto the in­ter­net for the world to see. I re­mem­ber my first pull-re­quest: it was­n’t pretty ei­ther.

But I want to high­light a cou­ple rea­sons why I want po­ten­tial con­trib­u­tors to open their pull re­quests as early as pos­si­ble.

Drafts Reduce Duplicate Work

When a con­trib­u­tor to a pro­ject is as­sess­ing the vi­a­bil­ity or use­ful­ness of some work they’re prepar­ing to do, most look at ex­ist­ing Pull Requests first. Even if you’re still work­ing on the patch, it’s a great idea to open a “draft” PR so no one starts work that could go to waste.

Further, if you have a draft open whose CI is fail­ing, a main­tainer may see it and fix what­ever the prob­lem may be. I find my­self fre­quently brows­ing Harper’s Pull Requests look­ing for fail­ing builds, since I’m of­ten the best equipped to find the is­sue.

It Helps With Debugging

I try to make my­self avail­able to con­trib­u­tors in case they have any ques­tions re­gard­ing the ar­chi­tec­ture of Harper. I’m also game to help de­bug their code, partly be­cause I am of the opin­ion that de­bug­ging is a skill which is best learned by ex­am­ple.

But it is hard for me to de­bug code if I don’t have it. If a draft PR has been opened, I can usu­ally see the prob­lem with­out even cloning the code, since our CI is so com­pre­hen­sive.

Conclusion

So please don’t wait; open that PR. I am thrilled each time I see a name I don’t rec­og­nize on a GitHub no­ti­fi­ca­tion.