Ben Balter is a Senior Product Manager at GitHub, the world’s largest software development network, where he oversees the platform’s Community and Safety efforts. Named one of the top 25 most influential people in government and technology, Fed50’s Disruptor of the Year, and winner of the Open Source People’s Choice Award, Ben previously served as GitHub’s Government Evangelist, leading the efforts to encourage government at all levels to adopt open source philosophies for code, data, and policy development.
[ my public key: https://keybase.io/benbalter; my proof: https://keybase.io/benbalter/sigs/IwMvqtA_GWJDFWYDQHIQsxuBRhWp49sX27fK_Qlu_u4 ]
Submissions
[untitled]
1 points·by benbalter··0 comments
Show HN: An MCP server that turns async-work practices into tools
github.com
22 points·by benbalter··9 comments
No Agenda, No Meeting
noagendanomeeting.net
7 points·by benbalter··1 comments
Practice Inclusive Scheduling
ben.balter.com
1 points·by benbalter··1 comments
Pull requests are a form of documentation
ben.balter.com
7 points·by benbalter··1 comments
Meetings are a point of escalation, not the starting point of a conversation
ben.balter.com
2 points·by benbalter··2 comments
Nine things a (technical) program manager does
ben.balter.com
2 points·by benbalter··0 comments
Resolutions for Sustaining and Growing Open Source Communities
hackernoon.com
1 points·by benbalter··0 comments
Use any theme with GitHub Pages
github.com
4 points·by benbalter··0 comments
SUPPORT file support on GitHub
github.com
2 points·by benbalter··0 comments
Open source license descriptions and metadata for GitHub repositories
github.com
5 points·by benbalter··0 comments
Behind GitHub's decision to standardize on one Markdown engine for GitHub Pages
github.com
2 points·by benbalter··0 comments
Upgrading your Textile posts to Markdown
github.com
2 points·by benbalter··0 comments
The six types of pull requests you see on GitHub
ben.balter.com
1 points·by benbalter··0 comments
25 reasons why you should consume, publish, contribute to, and support open source
ben.balter.com
1 points·by benbalter··0 comments
Four characteristics of modern collaboration tools
ben.balter.com
1 points·by benbalter··0 comments
Contribute to OpenStreetMap from GitHub
github.com
9 points·by benbalter··1 comments
Speak like a human: 12 ways tech companies can write less-corporate blog posts
ben.balter.com
2 points·by benbalter··0 comments
Lessons learned hacking on GitHub Pages for six months
Partially licensing, but also tokens + efficiency. As noted above, the book is written for humans (anecdotes, examples, etc.). Robots just need the facts and can extrapolate. If I were building a hosted service, a custom LLM with embeddings would probably beat both approaches.
This was my first "real" MCP server (previously I made an MCP server to control a Furby for GitHub Universe) and I learned a lot. A few things I learned (not an expert):
* Tool vs. Resource: Does it compute or does it serve
* Prompts -> Tools
* Deterministic vs. Probabilistic is a choice per tool
> the book's website and blog appear interesting, the author can write
I'll take the compliment!
README was 100% intended for robots, not humans (book is 100% for humans, FWIW). I'd be impressed if you can spend $10 on tokens interacting with the MCP. That's one reason why I went with an MCP over a skill. A lot of the logic is offline/token free.
Fixed rubric. It works on regex matching across interpersonal tension, active incident, sensitivity, and ambiguity. If a pattern matches, it weights sync over async.
More than a decade ago, I adopted the self-imposed rule, if I answer a question more than once, the third time I need to be able to answer with a URL. Today, I published one very large URL - a book distilling what I learned from helping people work remotely at GitHub, and I wanted to rethink my rule for the age of AI.
What if, instead of a URL, I could create an interactive experience that could tailor the guidance to your particular situation?
What I ended up building was an Open and Async Advisor MCP server. To install (in claude or any other AI):
> claude mcp add open-async -- npx -y @open-and-async/mcp
Transparently, yes, it's from a book I wrote which launched today, but the MCP server is open source and free to use. No purchase required. It knows the key principles of the book, and has specialized tools like `draft_decision_doc`, `convert_meeting_to_async`, `score_status_update`, `triage_sync_vs_async`.
This is an experiment for me, and I'm genuinely curious if it's helpful for others.
TL;DR: When working as a distributed team, be mindful of cultural differences, time zones, encouraging breaks between meetings, and connecting as humans.
TL;DR: When authoring a pull request, use the body as an opportunity to document the proposed change, especially the “why”, and cross link any related issues or other PRs to create a trail of breadcrumbs for future contributors.
Default to transferring context asynchronously. Hold colleagues accountable for being async first. If you receive a meeting invite without context, an agenda, or a read-ahead doc, consider politely declining.
PiHole is what first introduced me to the DNS sinkholing concept and was more mature when I was first researching options. AdGuard home has come a long way since then and I’m planning on giving it a closer look when I’m looking for my next project.
> A lack of knowledge hoarding, healthier knowledge transfer and decision making, and reduced waste.
Author here, +100 to this. The role of the PM should be to drive consensus around the problem, not to decree the problem (or requirements) by fiat.
For me, that process is highly collaborative, and engineers (and design, support, etc.) should 100% be involved from the begining. The amount of definition will vary from team to team and even engineer to engineer, but if a PM is hoarding knowledge, their understanding of their own role is the opposite of what it should be.
To paraphrase a famous product manager at Initech, "I talk to the customers so the engineers don't have to". That's not to say the engineers shouldn't talk to customers, but generally speaking, PMs should be the ones conducting qualitative and quantitative research day-to-day so that everyone can focus on what they do best.
At least on my teams, for example, user interviews are recorded and shared with the entire team, along with their raw notes, as are the high-level takeaways, allowing everyone to opt-in to as much or as little context as they'd like. We treat quantitative research the same way, sharing the underlying query, raw data, etc.
While the PM may ultimately drive the discussion, problem definition should be collaborative so that the entire team is aligned around a shared product vision. The PM's role should be to gather, organize, and share knowledge to build consensus, not to hoard it.
When you request an archive of your data, we send the download link to your primary email address (the required token is not available via the web UI). Once you click that link, you'll be asked to re-enter your password. So for this particular feature, an attacker would need both your GitHub password (and your 2FA seed or an active session if 2FA is enabled) and access to your email.
Did I miss something? Is there not a way to use 1Password 7 without it automatically uploading your 1Password 6 vault to their cloud as part of the setup flow (as it did for me)? Unless I did something wrong, it looks like a my.1password.com account is _required_ in 1Password 7.
See the section on "Sexually obscene content" in the GitHub Community Guidelines (https://help.github.com/articles/github-community-guidelines...). We purposely chose the word "obscene" and not "explicit" to allow for explicit but educational, scientific, or artistic content like this.
I am the Product Manager for GitHub Pages. As has been mentioned multiple times here, the usage limits were not in response to a specific external event. The limits have been an internal policy (in one form or another) for as long as I've been involved (nearly 4 years now), and we chose to publicize them in a series of updates beginning early this summer.
This is a classic case of "this is why we can't have nice things". If you're using GitHub Pages for your personal site or to document/talk about the work you're doing on GitHub, in general, you should be fine, even if you get HN-level traffic every once in a while.
The problem comes when a small handful of users use GitHub Pages for things like automated version checks or configuration distribution, as a makeshift ad CDN for for-profit sites, pushing an automated build every minute, or to distribute large assets (for which things like Releases are a better fit).
When a user (ab)uses GitHub Pages in a way that threatens our ability to build or serve other users' sites, technically or practically, we need to step in, and those posted limits are intended to help set expectations as to what you should and shouldn't use GitHub Pages for. But again, the vast majority of the nearly 1M users that use GitHub Pages will never hear from us (and in most cases when they did, we proactively reached out and provided ample warning/offered to help).
We may make things more flexible down the line, but for now, it was motivated by two primary reasons:
1. The overwhelming majority of users use one of those three design patterns. For example, I can tell you that more than 98% of GitHub Pages sites use either `master` or `gh-pages` as their primary branch (with only about one tenth of one percent of sites using the `stable` branch).
2. Our experience tells us that every option we add to GitHub Pages increases the learning curve for newer developers. With only those three options, if you're just learning HTML, you don't need to understand Git's branching model before you can create your first website.
We chose these options to start because we thought they struck a good balance between supporting collaborative documentation workflows for open source projects and encouraging "hello world" experimentation among new developers, but as with most features at GitHub, this is just the start.
[ my public key: https://keybase.io/benbalter; my proof: https://keybase.io/benbalter/sigs/IwMvqtA_GWJDFWYDQHIQsxuBRhWp49sX27fK_Qlu_u4 ]