HN user
Ben Balter. Spent more than a decade at GitHub, most recently as Director of Hubber Enablement. Former Presidential Innovation Fellow; recovering lawyer turned engineer/PM.
Wrote Open and Async, a playbook for working in the open and communicating asynchronously — the open-source way of working, turned into a method for teams: https://open-and-async.com
https://ben.balter.com · https://github.com/benbalter
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.
Please don't send meeting invites without an agenda.
Imagine getting a calendar invite that just says "Quick sync" with zero context… and having no idea what it's about.
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.
Is there a discussion somewhere that outlines some of the reasoning behind this pick?
Yes. The decisions was actually made on the open source GitHub Pages Gem repo, based on both user feedback and actual usage stats: https://github.com/github/pages-gem/issues/179.
They work just like any other Markdown file, and you can include a link in the rendered site to edit. See http://ben.balter.com/2015/09/13/github-pages-edit-button/.
From the original post:
The rank represents languages used in public & private repositories
The delta is due to private repository usage influencing the rank.
Rank is number of repositories with that language created in a given year, so e.g., the languages with the most repositories created would be ranked 1, the second most 2, etc.
Source: I ran the query.
What do you mean by commercial offering? A paid version of GitHub Pages? What would you want to see in a paid offering that couldn't be baked into the current version?
Do you have a wishlist of features to add to GitHub pages? Maybe allowing minimal sandboxed server side computation with a max runtime of say 1ms, setting headers, redirects or other stuff? I am guessing every little addition would eat away at the alternatives.
Moving from WordPress, the fact that you couldn't constantly tweak a thousand little things was extremely liberating. That's the zen-like simplicity of GitHub Pages that to me, makes it an attractive option over heavyweight alternatives. Just push and your site is live. Fewer things to break and fewer things to worry about means more time to focus on what matters: your content.
Ben from GitHub here. We don't offer an SLA for GitHub Pages (or GitHub.com generally).
We've talked a bit about our typical traffic in the past (https://github.com/blog/1992-eight-lessons-learned-hacking-o...), but suffice to say, we host some highly trafficked sites like the Bootstrap documentation.
If your blog isn't on that scale, and conforms to our terms of service (https://help.github.com/articles/github-terms-of-service/#g-...), we generally don't enforce hard usage quotas, but if you're concerned, feel free to reach out to support@github.com any time.
A couple months ago, the entire thing collapsed on my face and we went with gitlab instead. Why? Because github's sales team f*ed it up. Apparently, the $5k minimum order was too small for them to care (at least that's what my side says). Too bad, I really wanted to get them in the door.
Ben Balter from GitHub's government team here. I'm sorry to hear we let you down. Please let us make it up to you. You (or anyone else) should feel free to reach out to me any time at government@github.com, and I'll personally help navigate the process.
For what it's worth, we care a lot about the experiences of all our users, whether you're a developer using the GitHub.com front end, a system administrator spinning up GitHub Enterprise, or a COTR procuring a license for your agency. I'm not part of the Sales team. In fact, my full-time job is to help empower those working to "fix/modernize gov't tech from the inside", and a big part of that over the past year or so has been seriously leveling up the user experience for government and other large enterprises.
To help here, we now have a dedicated government team (https://government.github.com) that makes sure our front-line sales reps and supportocats are conversant in "govspeak", a semi-private government peer group (https://github.com/government/welcome) to collaborate on best practices, and are streamlining the procurement process for government with invoicing and standardized contract vehicles (and now FedRAMP support as part of AWS). I'd love your input on how we can do better.
Yep. The `.nojekyll` option has been around since 2009: https://github.com/blog/572-bypassing-jekyll-on-github-pages
To be specific, all sites are processed through Jekyll, unless you add a `.nojekyll` file. Non-Jekyll files (like HTML or CSS) are passed transparently through Jekyll untouched. Adding the dashes to the file header simply tells Jekyll to work its magic.
Knew we should have used a bubble sort. Thanks for catching that. https://help.github.com/articles/github-glossary#pull-reques...
It installs Jekyll, and its dependencies, which users would have done normally, but explicitly locks the version into the same version used on the GitHub Pages server, ensuring that your local build environment matches the GitHub build environment as closely as possible. This is especially important when new versions of Jekyll are released (often with new features) and the GitHub pages servers are updated. Builds in one environment may otherwise behave differently from builds in another.