GitHub released a new Pull Requests dashboard in public preview at the end of March 2026. It replaces the existing pull request list at github.com/pulls with something that functions more like an inbox: a view that surfaces the PRs that actually need your attention rather than presenting every open PR you are associated with.
VS Code is a remarkable editor. It is fast, extensible, and free, and it has become the default tool for an enormous portion of the developer community. I use it myself for PowerShell, general Markdown, and lightweight editing. But when I sit down to write Go or Python, GoLand and PyCharm are where I do my best work.
This is not a condemnation of VS Code. It is an explanation of why, for language-specific work, purpose-built IDEs make me a more productive and deliberate developer.
GitHub renders Markdown with either a light or dark theme depending on the user's system or GitHub appearance settings. A logo or diagram that looks sharp on a white background can disappear entirely when the same user switches to dark mode. GitHub provides two ways to serve the correct image for each theme without JavaScript.
If you are using MkDocs Material, the same problem has a pure-Markdown solution covered in a companion post: Light and Dark Mode Images in MkDocs Material.
The MkDocs Material theme has built-in support for theme-aware images using standard Markdown syntax. No HTML is required.
Toggle the palette icon in the header to see the logo switch between its light and dark variants:
If you are using GitHub Markdown instead, see the companion post: Light and Dark Mode Images in GitHub Markdown.
Trigger Warning
This piece contains the death of a pet, childhood trauma, grief, and emotional neglect. Please read with care.
I was 13 the day I learned that love and safety were different things.
For years afterward, I remembered it as sounds. Not the worst sound, not even the one that should have mattered most, but the smaller ones that came before it, ordinary details preserved in perfect condition.
The bus brakes hissing on the county road.
The car engine idling with that low, stubborn tremor old engines have.
Gravel and clay ticking under the tires.
It was an afternoon like a hundred others, so ordinary it seemed beneath notice. Which is often how disaster arrives: without warning, dressed as routine.
Most pull requests arrive with a title, a branch name, and nothing else. The reviewer is left to reverse-engineer the intent from the diff, hunt through linked issues that may or may not exist, and ask follow-up questions before they can even start. That back-and-forth is a tax on everyone's time, and it is almost entirely avoidable.
A pull request template shifts the burden upstream. It prompts contributors at the moment they open a pull request to provide the context that reviewers need: what changed, why it changed, whether it breaks anything, and what issue it resolves. Done well, a template makes the review faster, the history more useful, and the project easier to contribute to.
This post covers what a pull request template is, how to set one up in a GitHub repository, and how to write one that contributors will actually fill out.
GitHub offers five certifications that validate skills across the full breadth of the platform: Foundations, Actions, Copilot, Advanced Security, and Administration. I completed each of these last year and found each one to be a genuine challenge that pushed me to revisit corners of the platform I thought I already understood.
This post walks through each certification, what it covers, how to prepare, and where to find the best study resources.
Alongside pinned comments for issues, GitHub introduced a quiet but effective change to how contributors interact with issue threads: a nudge that appears before a low-signal comment is posted, redirecting contributors toward a reaction or a subscription instead.
GitHub shipped a small but meaningful feature for issue tracking in February 2026: the ability to pin a comment to the top of any issue. It addresses a problem that every active open source project runs into sooner or later: the signal-to-noise ratio in issue threads starts degrading at exactly the moment when the thread matters most.
.github RepositoryEvery GitHub account, whether a personal profile or an organization with dozens of developers, eventually accumulates the same boilerplate problem. You add a CONTRIBUTING.md to one repository, a CODE_OF_CONDUCT.md to another, issue and pull request templates to a third, and none of them are consistent. When someone opens a new repository, they either copy files from an older one (hoping they are still current) or start from scratch.
GitHub has a solution to help set defaults: the .github repository. It is a specialized repository you create under your personal account or organization that acts as a default configuration layer for every repository that does not define its own. One place to maintain community health files, contribution guidelines, security policies, issue templates, and (for organizations) standardized workflow templates that appear in the Actions UI across every repository in the org.
This post covers what a .github repository is, what goes inside it, how to set one up, and an honest look at the benefits and the tradeoffs.