How Home Assistant Just Lost Another Contributor: A Story About Closed PRs and Broken Dreams

Social
1

My Journey from Bug Report to Bitter Disappointment

Three months ago, I stumbled upon issue #138413 in Home Assistant Core. As a newcomer to the project, I was eager to contribute and help make this amazing platform even better. The issue seemed straightforward: when users configure multiple Telegram bots in their configuration.yaml, messages are sent to the wrong chats. Users were reporting that their sensitive notifications were going to unintended recipients - a clear security and privacy concern.

“This should be fixable,” I thought. How wrong I was about the real challenge.

The Technical Deep Dive

Being new to Home Assistant’s codebase, I spent weeks understanding the architecture. I dove deep into the telegram_bot integration, traced through the code, identified the root cause, and developed a proper fix. The problem was clear: only the last initialized bot was being used for all messages, regardless of the target chat_id specified.

I implemented a solution that:

  • Maintains a list of all notification services
  • Routes messages through the correct bot based on target chat_id
  • Handles edge cases like overlapping chat_ids
  • Maintains full backward compatibility
  • Includes comprehensive tests covering all scenarios

The fix was elegant, minimal, and non-breaking. I followed every guideline, formatted the code properly, wrote extensive tests, and even signed the CLA.

The Code Review That Never Came

When I submitted PR #144922, I was excited. This was my first significant contribution to such a large open-source project. The automated tests passed, the code was clean, and I had addressed a real user problem.

Then came the response from maintainer:

“I don’t think we should fix this until we add support for config entries. It will make it easier to migrate and import the YAML to config entries if we don’t support more than one platform.”

I provided a detailed, respectful response explaining why this was critical:

  • Users are experiencing data loss (messages to wrong recipients)
  • It’s a security/privacy concern with sensitive messages
  • The fix is minimal and won’t interfere with future config flow work
  • Users reasonably expect documented configuration to work

His final responses?

  • “It has never worked to configure more than one platform so this isn’t a critical fix.”
  • “I’ll close here now.”

Just like that. Three months of my time, dismissed in two sentences.

The Real Problem: Broken Contribution Process

This isn’t just about my hurt feelings (though they are genuinely hurt). This exposes serious problems with Home Assistant’s contribution process:

1. Single Point of Failure Decision Making

One person unilaterally closed a thoroughly researched, tested, and implemented bugfix. No discussion with other maintainers, no technical review of the actual code, no consideration of the arguments presented.

2. “Not Broken Enough” Mentality

Claiming it’s “not critical” because “it never worked” is backwards logic. If users expect it to work (and the configuration suggests it should), then it IS broken and needs fixing. This attitude discourages fixing any long-standing issues.

3. Contributor Abandonment

After someone spends months learning your codebase, understanding your patterns, and implementing a proper solution, the minimum courtesy is a real technical review. Not a dismissive closure based on architectural preferences.

4. Perfect Future vs. Better Present

Blocking practical fixes because they don’t align with some future architectural vision means users suffer indefinitely. Good engineering is about iterative improvement, not waiting for perfect solutions.

The Bigger Picture

Home Assistant is an incredible project, but this experience shows why many potential contributors walk away:

  • High barrier to entry: Complex codebase requires significant time investment
  • Unpredictable review process: No guarantee your work will be fairly evaluated
  • Architectural dogma over user needs: Theoretical purity trumps solving real problems
  • Lack of contributor support: Newcomers aren’t guided or supported through the process

What Should Have Happened

  1. Technical review: Actually look at the code and tests
  2. Discussion: If concerns exist, discuss them with other maintainers
  3. Compromise: If the approach isn’t perfect, suggest improvements rather than closure
  4. Respect: Acknowledge the time and effort contributors invest

The Cost of This Approach

Every closed PR like this doesn’t just lose one fix - it loses a potential long-term contributor. I spent three months learning Home Assistant’s internals. That knowledge is now wasted because I’ve lost faith in the contribution process.

How many other developers have had similar experiences? How many bugs go unfixed because contributors give up after being dismissed?

A Call for Change

Home Assistant needs to:

  1. Establish multi-reviewer requirements for closing PRs with substantial work
  2. Create contributor mentorship programs to support newcomers
  3. Prioritize user-facing fixes over architectural purity
  4. Require detailed technical justification for PR closures
  5. Implement contributor feedback systems to improve the process

Conclusion

I still believe in Home Assistant’s mission. But I can no longer invest my time in a project where months of work can be dismissed in seconds by a single person’s arbitrary decision.

The telegram_bot bug still exists. Users still experience it. And now it will remain unfixed indefinitely because fixing “not critical” bugs apparently isn’t worth the effort.

To other potential contributors: be warned. Your time and expertise may not be valued here.

To the Home Assistant team: you’re losing contributors faster than you’re gaining them with this approach. The cost of architectural perfectionism is measured in unfixed bugs and abandoned contributors.

This post represents my personal experience and frustration. I hope it leads to constructive discussion about improving the contribution process for everyone.

TL;DR: Spent 3 months fixing a legitimate Home Assistant bug with proper code and tests. Maintainer closed PR in 2 sentences without technical review because it doesn’t fit their architectural roadmap. This process discourages contributors and leaves users with unfixed bugs.

26 Likes
2

I feel your pain.
What you can do: fork the integration, put in your fixes, and add it to HACS.
At least your work is not lost that way.

9 Likes
3

Firstly, thank you for volunteering your time to improve the project. Home Assistant would be a lot more spartan without volunteers like you generously donating their time.

It is unfortunate that you chose a notification platform for your first PR. The whole notification integration is in a bit of a state of flux because of this architecture discussion: Add new notify entity component ¡ home-assistant/architecture ¡ Discussion #1041 ¡ GitHub

So while things are moving slowly, there is a larger plan that is currently under way.

As explained in the issue (#138413), this isn’t actually a bug. The platform was not intended to support more than one bot. The real bug is that the platform allows more than one bot to be set up without warning.

If you do ever feel like opening a PR like this again I highly recommend discussing it in the developers Discord channel or opening an Architecture discussion first. It may reveal things like current architectural improvement plans you may be unaware of and help save a lot of wasted time.

Francis’s suggestion is also a good one if you do want to move forward with this. And having a large 3rd party userbase is of great assistance when trying to persuade the core team to move your code into the core.

6 Likes
4

Thumbs up for proposing a coordinated approach. Wouldnt this be something that could be documented/mentioned/linked somewhere rather on the frontpage of https://developers.home-assistant.io/ as well? The next saippuakauppias most likely will not bump into this thread, and then the story begins again…

2 Likes
5

I get it from the “his work would still be available” perspective. But would you really say that a significant number of people will search in HACS for a fix of an integration, that is otherwise known as part of the core? That sounds like a unlikely scenario to me. Or are there other examples where this worked out?

Which also makes me doubt this here to actually work “in the real world”:

Don’t get me wrong guys, I sincerely believe that you care about OP’s bad experience, and that you’re trying to point out options to soften the blow. I just don’t understand how the concrete proposals will translate into things that will make a difference.

6

Kudos for not just sharing your pain, but also proposing improvements.
I’d add a point 0.5 or 6:

  • Document organisational best practices in a way that people will easily find them before significant effort is put into stuff

That might be partially covered by what you called a “mentorship program”, but should be possible to establish at least a bit easier than full-blown mentorship.

3 Likes
7

Definitely. From HACS I use Home Connect Alt, Tuya Local, iCloud v3, Proxmox VE, Spotcast, and probably more because they all offer something more than the core integrations.

8

For additional features I get that. But the situation that OP was trying to fix mostly would show itself as a bug to the users (“I can easily set multiple ones, but somehow it doesn’t work correct, so something must be broken”), not a “I’m missing a feature, let me look around if I find it somewhere else” situation.
At least I understand your examples as cases where it’s about additional functionality, did I get that right?

1 Like
9

Yes and no - generally I was driven to these HACS solutions because there was something “wrong” (IMO) with the core integration. For example the Tuya integration provides everything I need and I didn’t care about local vs cloud, but I found it very flaky - entities just not updating state. Hence I went looking elsewhere.

10

Being able to use more then telegram bot would count as extra functionality.

1 Like
11

Agreed. And maybe specifically the current behaviour of the telegram integration is an unfortunate “middle ground”: it doesn’t break in an obvious way when you try it, it even somehow partially works. So you could argue both ways.

EDIT: maybe I’ll write 1-2 extra lines for the documentation to at least make it clear that people shouldnt even try. Let’s see if that pull request makes it through :wink:

grafik
grafik1286×751 66.4 KB

12

Contrary to this, it may not have been designed as you say, but fact is that one could do multi config while only one was used at the end. OP could either fix the error allowing one to have multi config, or implement an option to use multi configs properly. OP chose option 2.

Personally, I don’t see a valid reason why having more than 1 config would be an architectural change if it doesn’t break any single thing from the history.

IMO, this PR should have been accepted. What bothers me even more is that the replies he got on Github are a single statement, clearly “I am the one who is right here, period, end of story” while OP wrote clear reasoning.

5 Likes
13

The whole notify integration is changing. PRs perpetuating the old system are unlikely to be accepted, especially if they are not bug fixes. Which this wasn’t.

1 Like
14

Are adjustments to the documentation for the meantime still okay? if so:

2 Likes
15

If replies to the PR would explicitly mention this, I’m sure OP would not be disappointed as he is now when he got a dictatorship’s “NO” as an answer.

Thanks for Your reply tho.

1 Like
16

I hope so.

They did:

I don’t think we should fix this until we add support for config entries.

17

As a person who contributes to the code base quite a bit, what OP should have done was kept PR on hold as a draft and waited until the config flow PR was merged (that pr is 2 weeks old at this point). Then when it’s merged, rebase their PR, fix conflicts and add the feature. It would have gotten through without any pushback.

The config flow PR was first by 4 days and it drastically changes the code base for that integration. Martin made OPs PR a draft and laid out the reasons. OP decided to ignore the comments, argue, and re-mark it for review. Just to put this into perspective, marking a pr ready for review without making changes usually puts the PR into purgatory. It’s a death sentence because it shows OP isn’t willing to work with others.

Sorry OP, but that type of behavior is the telltale sign of a person who is ready to start a long and drawn out argument instead of working with the upcoming changes. It’s unfortunate it happened this way, however the blame is not solely on HA here.

6 Likes
18

That’s not true.

First, the proposed PR above is adding new functionality.
Second, my fix does not break that PR.
Third, my PR fixes a bug.

I wrote about all of this right here: Fix send telegram notification to multiple chats by saippuakauppias ¡ Pull Request #144922 ¡ home-assistant/core ¡ GitHub

19

Except that’s not the bug. This is: How Home Assistant Just Lost Another Contributor: A Story About Closed PRs and Broken Dreams - #14 by Lakini

20

Isn’t telegram for people without security and privacy concerns?

Telegram has lots of features and encourages the development of third-party clients. It’s probably the best messenger if you don’t care too much about privacy. The main downside is that chats are not E2E encrypted by default…

Comparison of Instant Messengers

1 Like