Hacker News: benbalter

New comment by benbalter in "No Agenda, No Meeting"

benbalter — Sun, 05 Apr 2026 17:53:53 +0000

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.

No Agenda, No Meeting

benbalter — Sun, 05 Apr 2026 17:53:53 +0000

Article URL: https://noagendanomeeting.net

Comments URL: https://news.ycombinator.com/item?id=47652009

Points: 7

# Comments: 1

New comment by benbalter in "Practice Inclusive Scheduling"

benbalter — Thu, 25 May 2023 15:24:29 +0000

TL;DR: When working as a distributed team, be mindful of cultural differences, time zones, encouraging breaks between meetings, and connecting as humans.

Practice Inclusive Scheduling

benbalter — Thu, 25 May 2023 15:24:29 +0000

Article URL: https://ben.balter.com/2023/05/19/practice-inclusive-scheduling/

Comments URL: https://news.ycombinator.com/item?id=36071946

Points: 1

# Comments: 1

New comment by benbalter in "Pull requests are a form of documentation"

benbalter — Thu, 25 May 2023 15:24:16 +0000

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.

Pull requests are a form of documentation

benbalter — Thu, 25 May 2023 15:24:16 +0000

Article URL: https://ben.balter.com/2023/05/19/pull-requests-are-a-form-of-documentations/

Comments URL: https://news.ycombinator.com/item?id=36071939

Points: 7

# Comments: 1

New comment by benbalter in "Meetings are a point of escalation, not the starting point of a conversation"

benbalter — Fri, 21 Apr 2023 15:43:35 +0000

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.

Meetings are a point of escalation, not the starting point of a conversation

benbalter — Fri, 21 Apr 2023 15:43:35 +0000

Article URL: https://ben.balter.com/2023/04/20/meetings-are-a-point-of-escalation/

Comments URL: https://news.ycombinator.com/item?id=35655486

Points: 2

# Comments: 2

New comment by benbalter in "How I re–over-engineered my home network for privacy and security"

benbalter — Fri, 03 Sep 2021 03:38:44 +0000

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.

Nine things a (technical) program manager does

benbalter — Fri, 26 Mar 2021 17:12:36 +0000

Article URL: https://ben.balter.com/2021/03/26/nine-things-a-technical-program-manager-does/

Comments URL: https://news.ycombinator.com/item?id=26594508

Points: 2

# Comments: 0

New comment by benbalter in "Problems, not solutions (2018)"

benbalter — Fri, 14 Feb 2020 18:14:20 +0000

> 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.

Resolutions for Sustaining and Growing Open Source Communities

benbalter — Thu, 02 Jan 2020 17:00:04 +0000

Article URL: https://hackernoon.com/resolutions-for-sustaining-and-growing-open-source-communities-h91e3zil

Comments URL: https://news.ycombinator.com/item?id=21937077

Points: 1

# Comments: 0

New comment by benbalter in "Download all of your GitHub data"

benbalter — Wed, 19 Dec 2018 22:13:36 +0000

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.

New comment by benbalter in "The 1Password 7 Beta for Mac"

benbalter — Wed, 28 Mar 2018 20:34:21 +0000

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.

Use any theme with GitHub Pages

benbalter — Wed, 29 Nov 2017 20:53:28 +0000

Article URL: https://github.com/blog/2464-use-any-theme-with-github-pages

Comments URL: https://news.ycombinator.com/item?id=15810729

Points: 4

# Comments: 0

SUPPORT file support on GitHub

benbalter — Thu, 20 Jul 2017 22:33:19 +0000

Article URL: https://github.com/blog/2400-support-file-support

Comments URL: https://news.ycombinator.com/item?id=14816825

Points: 2

# Comments: 0

Open source license descriptions and metadata for GitHub repositories

benbalter — Thu, 16 Mar 2017 20:26:30 +0000

Article URL: https://github.com/blog/2335-open-source-license-descriptions-and-metadata

Comments URL: https://news.ycombinator.com/item?id=13888854

Points: 5

# Comments: 0

New comment by benbalter in "GitHub Pages – Usage Limits"

benbalter — Wed, 21 Dec 2016 15:56:08 +0000

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.

New comment by benbalter in "GitHub Pages – Usage Limits"

benbalter — Wed, 21 Dec 2016 14:44:57 +0000

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).

New comment by benbalter in "Simpler GitHub Pages publishing"

benbalter — Wed, 17 Aug 2016 20:36:41 +0000

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.