Preface: This post is specifically about Pull Requests for Harper. Read the contributor guidelines for a project before opening a PR.
I get it. Opening a pull request is an intimidating proposition.
It is non-trivial to put your blood, sweat, and (let's be honest) tears into code and put that onto the internet for the world to see. I remember my first pull-request: it wasn't pretty either.
But I want to highlight a couple reasons why I want potential contributors to open their pull requests as early as possible.
When a contributor to a project is assessing the viability or usefulness of some work they're preparing to do, most look at existing Pull Requests first. Even if you're still working 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 failing, a maintainer may see it and fix whatever the problem may be. I find myself frequently browsing Harper's Pull Requests looking for failing builds, since I'm often the best equipped to find the issue.
I try to make myself available to contributors in case they have any questions regarding the architecture of Harper. I'm also game to help debug their code, partly because I am of the opinion that debugging is a skill which is best learned by example.
But it is hard for me to debug code if I don't have it. If a draft PR has been opened, I can usually see the problem without even cloning the code, since our CI is so comprehensive.
So please don't wait; open that PR. I am thrilled each time I see a name I don't recognize on a GitHub notification.
A guide for adding a new programming language to the Harper language server.
After receiving some feedback related to the suggestion box's visual unpleasantness and difficulty to understand intuitively, I've started making some modifications. Nothing drastic—I don't want to confuse existing users.
A key part of Rust is far better than what JavaScript has to offer.