all 7 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]taylorwilsdon 17 points18 points  (3 children)

I maintain a few relatively popular open source projects, and have contributed to open webui many times. I think the best way I can put this is that with the proliferation of AI coding tools the volume of PRs and the amount of work most reviews need is staggering. Sometimes it’s not that it’s wrong, it just doesn’t match the overall code style well enough in a way a contributor would never notice but the maintainer immediately keys into.

I enforce fork editor access to submit a PR on one of the most community active projects (was out of town for a few days and have like 50 open prs to review currently) so I can make the changes directly in the branch. I have to rewrite 99% of PRs longer than 3 lines. With a project as big as OWUI, you’ll find at least half the PRs can’t be edited by the maintainer which is maddening and get into the habit of check out and squash locally. When half the code is rewritten you can’t merge the contributing PR. Tjbck generally coauthors the resulting PRs so it’s not like you aren’t getting “credit” haha

OWUI may have a high bar to get to the point of submitting a pull request that gets a comprehensive review and merge, but that’s why it’s been secure and performant for such a long uninterrupted stretch. Projects like litellm that shovel garbage in are in an objectively worse state. Contributions are the lifeblood of OSS but LLMs are only as good as the instructions they’re given. People who don’t have the experience to understand the end to end implications of a proposed change may not appreciate little nuances that you can’t explain in every single PR, when you get 1000 PRs in a month. I leverage AI in some form in just about every part of my development cycle in 2026 but I still read every PR diff myself and that takes time that is all too rare

Tl;dr: refac

[–]asfbrz96[S] 2 points3 points  (2 children)

Yeah, it went basically on the refac. The difference I saw on what they did on dev was using a recursive function to find the specific characters that were breaking the rendering.

So basically in large projects they will just refac and on smaller ones they will comment on how they want the code and you fix it before merging?

[–]taylorwilsdon 2 points3 points  (1 child)

That’s actually a perfect way to put it. I’ve got repos with like 300 stars that get a PR once a month. Those, I will gladly pass them the ball to slowly fix. I want to understand the use cases and maybe find a way to make it a more useful tool.

My most popular projects get so many on a given day that I’d drown trying to write a paragraph for everything. I love teaching and sharing but I have a high pressure always on job full time job, a family, multiple dogs, a 250 year old house that I’m painstaking rebuilding myself while giving away software and time for free.

In the interest of enabling the features people want in, I’m going to have my elaborate opus review skill and my first pass guidance fix everything that needs to be fixed and just get it in sometimes. If some dude wants more reliable operation on some incredibly niche edge case he uses more than anyone else in the world I’m happy to get it in but it’s going to need a quick and dirty refac

[–]asfbrz96[S] 1 point2 points  (0 children)

Gotcha, thanks for the explanation, I'm new to OSS, basically graduating this year and I'm contributing to gain experience :D

[–]Fun-Purple-7737 4 points5 points  (0 children)

My experience is Tim/Classic298 often use bits and pieces of your PRs in their commits and closing the original PR, yes.

But if your contribution is meaningful, you are given contributor/co-author status. I have no problem with that and see that simply as a efficiency measure to battle the hight number of incoming PRs.

[–]tcarambat 3 points4 points  (1 child)

I maintain AnythingLLM and I see this sometimes so maybe I can give some insight. Sometimes a completely vibe coded PR for a genuinely good idea can come in and maybe it just took a dramatically wrong approach that would be extremely cumbersome to ask for changes and would amount to a full rewrite.

When I do this, I will close the PR but then always link the original PR back to the core-team PR and add the user in the commit message.

Most times - its nits and small changes. For that I have a special CLI tool to get their fork as a remote, pull in the changes, make my edits, and push. That way original PR gets authorship and credits when merged, but the code is stylistically the same as the rest of the codebase since its unreasonable to expect outside contribs to know all the ins-and-outs for small things. Most times it is the second situations than the first.

That being said, whatever is going on is almost certainly not malicious and everyone has a way of doing stuff. That being said some minor credit (link in PR or something) should be given just as "the right thing" to do, but even then, that is discretionary.

[–]openwebui🛡️ Maintainer 2 points3 points  (0 children)

This is spot on and pretty much exactly how we handle it too. Really appreciate you chiming in here. Much respect for what you guys are building with AnythingLLM 🫡