I personally find AI doomsday preaching incredibly arrogant. You think that we will create super intelligence, something that will exponentially get smarter, and the thing it will do is... end humans? Why wouldn't it just find solutions to problems we struggle with? Also people don't live to work, its asinine to argue AI replacing jobs is the problem, obviously the problem is the gains being concentrated higher up. Another thing is, we argue AI needs to be maximally useful to everyone in the world, and the argument to do that is government control??? I would rather push for AI to be superintelligent faster than any one human can control it. Frankly human controlled superintelligence is likely a worse outcome then uncontrolled superintelligence, at the very least there is no guarantee one will be better than the other.
So this is exactly what's unintuitive about queues, an analogy would be car lanes. Intuition might lead you to conclude that if a 2 lane road has traffic constantly going to 4 lanes will solve the traffic. But this is not true. Many people that would have used the road might have been using public transport or just decided not to commute or stay inside normally will join the traffic until it once again equilibriates. Adding more maintainers without addressing the core problems of the queue won't lead to success
Fair call-out, although couple things to point out, I am used to a Squash Merge workflow which I think makes reviews easier based on comments as the reviewer gets to see what changed after their comment easier. Many of the commits are merge commits. If you actually look at the timeline of the original PR, you will see that it also started with a smaller scope but as time passed I also went through the cycle of "while at it, let me also fix this" loop that I mentioned in the article.
The point of the article is: there is a feature that people would like, there is someone who wants to add it, the appropriate time and a lot more for this feature to be merged has been spent yet the feature is nowhere to be found. That's the two way street I am trying to get across. I wish I wasn't even able to open the PR, I wish the maintainer would utilize more automation tools to groom feature requests and potential contributors with agreed upon plans and agreed upon timelines so that both sides time could be used much more effectively.
As far as PR descriptions etc goes, I asked multiple times what the best route to merging would be. If that went through better descriptions, I was happy to do that, as you can see, I wasn't aware of the "no conventional commits" rule, so in my next PRs I used the correct approach, but that should be completely automatable. Yes, I should have spent more time studying Jellyfin's conventions, but I shouldn't have to, not because its unfair for me, simply because there are more contributors than maintainers, so maintainers should not rely on desired behavior from contributors, they should force that behavior as much as possible.
Agreed. A problem I see with how AI reviews have been used is that after one kicks it off, now the maintainer has to review both the PR and the AI's review which doesn't really save time. Like you said, if AI review was used more intentionally, e.g. all PRs have to go through AI review that checks for the baseline requirements and only after the contributor signals "I addressed everything AI commented either by giving my disagreement reasons or making the changes", maintainers spending time on the review could save a lot of quality time.
Thanks a lot! I appreciate the kind words. I do want to clarify that I think in Jellyfin-web's case, the maintainer does mean well and doesn't really have the "benevolent dictat... er, maintainer" approach. But there seems to be this defeatist argument of: we have one maintainer which means 6 months per PR and features not being merged, that I think Open Source projects could do a better job at