<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Hacker News: heurekamala</title><link>https://news.ycombinator.com/user?id=heurekamala</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Wed, 30 Sep 2026 04:20:10 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=heurekamala" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by heurekamala in "Open Source Stewardship Communities: "We need you, but not your pull request""]]></title><description><![CDATA[
<p>I think the paper looks at the wrong problem. 
It treat gating like the thing that breaks the contributor pipeline, but I think a lot of this pipeline was already gone before anyone closed the door.
The old way worked because when you write a patch and  you had to learn the codebase before. 
And talking in the review made a relationship with the maintainer. But a PR someone make in ten minutes don't do this. 
The person who submit learns nothing about the architecture, and maintainer learns nothing about the other person. 
The review is just the maintainer doing the work two times. The form is still there, but not the substance. Gating just shows this. For me, it is more interesting where motivation comes from now. When an AI agent write the code, writing a good issue is much closer to real work than a PR ever was. You need to understand the project really good to describe the problem, the context, and edge cases.<p>Getting credit when a bug is fixed, test pre-releases, feedback buttons inside the app: this feels like much better places to invest instead of trying to save the PR as social ritual.
I had a few own projects, and it was really not easy to get people contributing. But getting good feedback to make the project better was much more easy.<p>So maybe we need a less technical way for engaging with the community.
Where the authors are right, I think, is succession. A person who write great issues still don't know the
code good enough to take over if the maintainer leaves. People can engage with issues and feedback, 
but maintainability don't work like that. And I haven't seen a good answer yet how the next maintainer should learn the system if they never had reason to read it.<p>Maybe we need a way to give the users a better way to give feedback to the project and make their feedback showable in the project. This is also important for many people.</p>
]]></description><pubDate>Tue, 29 Sep 2026 11:15:45 +0000</pubDate><link>https://news.ycombinator.com/item?id=49891304</link><dc:creator>heurekamala</dc:creator><comments>https://news.ycombinator.com/item?id=49891304</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49891304</guid></item><item><title><![CDATA[New comment by heurekamala in "Show HN: Arcentry – Create 3D infrastructure diagrams"]]></title><description><![CDATA[
<p>It is a nice idea, but I need more examples on your page to decide, if this is something for me. I am building a project management platform and maybe this is a useful extension, but I am not sure of this is only nice to play with or usefull for my users.</p>
]]></description><pubDate>Mon, 28 Sep 2026 12:40:00 +0000</pubDate><link>https://news.ycombinator.com/item?id=49877043</link><dc:creator>heurekamala</dc:creator><comments>https://news.ycombinator.com/item?id=49877043</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49877043</guid></item><item><title><![CDATA[New comment by heurekamala in "Footguns with Postgres “at time zone 'UTC'”"]]></title><description><![CDATA[
<p>The text says: "Comparing a timestamp and timestamptz will always result in false."<p>That is wrong. Postgres changes the timestamp to timestamptz very quietly in the background. 
Wether it uses the time zone of the session for this. 
If it is true or false depends on the TimeZone setting. This is more bad than "always false". 
In production with UTC it works. On a laptop of a California developer it does not work.<p>Just tested:<p><pre><code>  SET TIME ZONE 'America/Los_Angeles';
  SELECT '2026-03-01 00:00:00'::timestamp = '2026-03-01 00:00:00+00'::timestamptz; /* f   */

  SET TIME ZONE 'UTC';
  SELECT '2026-03-01 00:00:00'::timestamp = '2026-03-01 00:00:00+00'::timestamptz; /* t  */
</code></pre>
If you can, use Postgres 16. 
The double AT TIME ZONE 'UTC' thing from the text is not needed there. There you have date_add with a time zone as the third argument:<p>date_add(b.month_start, interval '1 month', 'UTC')<p>This adds the month in UTC and it stays a timestamptz.</p>
]]></description><pubDate>Mon, 28 Sep 2026 10:40:16 +0000</pubDate><link>https://news.ycombinator.com/item?id=49875982</link><dc:creator>heurekamala</dc:creator><comments>https://news.ycombinator.com/item?id=49875982</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49875982</guid></item><item><title><![CDATA[Jev Benchmarks]]></title><description><![CDATA[
<p>There are comming more and more Jev alternatives. Is there anywhere a benchmarklist of these jev competitors?</p>
<hr>
<p>Comments URL: <a href="https://news.ycombinator.com/item?id=49849006">https://news.ycombinator.com/item?id=49849006</a></p>
<p>Points: 1</p>
<p># Comments: 0</p>
]]></description><pubDate>Fri, 25 Sep 2026 19:41:14 +0000</pubDate><link>https://news.ycombinator.com/item?id=49849006</link><dc:creator>heurekamala</dc:creator><comments>https://news.ycombinator.com/item?id=49849006</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49849006</guid></item><item><title><![CDATA[New comment by heurekamala in "Show HN: An atlas of system designs with interactive architecture diagrams"]]></title><description><![CDATA[
<p>Really nice! It’s also a good reminder that there is always more to discover. Even when you think you know it all.</p>
]]></description><pubDate>Tue, 22 Sep 2026 14:23:53 +0000</pubDate><link>https://news.ycombinator.com/item?id=49801819</link><dc:creator>heurekamala</dc:creator><comments>https://news.ycombinator.com/item?id=49801819</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49801819</guid></item></channel></rss>