heurekamala

This sounds a little bit like a tension cycle so we have now for example also in IT the problem that young graduates from university currently get no jobs anymore This will lead to it that we in ten years will probably get a problem in IT becuase we simply lack the new generation We do not know it exactly It can of course also be that much less demand is there But it could also be that although very many jobs are cut we then still have a gap in the demand. In the trades exactly the oppisite could happen: that there is an oversupply of workers whereon then the wages will sink very strongly. Therefore I would now reccomend young people, young humans who are maybe still in the middle class in school to maybe orient themselves in the IT area after all.

Cool work. There are some of this educational gems here. Is there a site which combines these treasures (like in a virtual museum?)

If I would pay 500 bucks, I would squeeze as much as I can. Won't you?

We must keep in mind, that even the 500 plan is not cost-covering for many users. Heavy users squeezing everything out of it. It is like the Internet-fees in the end 90s. The flat-rate was not cost-covering by heavy users and I think these plans are only used by heavy users. Maybe we really come to an end of cheap KI and we will use all an mac studio m10 in a few years.

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.

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.

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.

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.

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.

The text says: "Comparing a timestamp and timestamptz will always result in false."

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.

Just tested:

  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  */

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:

date_add(b.month_start, interval '1 month', 'UTC')

This adds the month in UTC and it stays a timestamptz.

Really nice! It’s also a good reminder that there is always more to discover. Even when you think you know it all.