Frustrated of FastAPI slow development · fastapi fastapi · Discussion #3970

There are plenty of good PR asked by a lot of people. No response from @tiangolo There are painful bugs like #3665 that we don't know if it will be fixed or not. Very few commits merged except documentation Thanks a lot for what you did @tiangolo but you should find additional mainteners to help. ... I'm also starting to be a bit disillusioned. After nice experience in the development phase of a new project with FastAPI, we are facing various problems when moving to production. Starting from the official documentation, where the described DB integration using dependencies leads to deadlocks with more concurrent users (#3205), reported in May, and ending with various features sort of necessary for production usage where PR has been created a long time ago, but without any reaction, e.g. hiding selected attributes from Swagger, hiding internal documentation from Pydantic models docstrings etc. … Those are not many, but still, another chunk of "issues" that are not really issues and are not expected to be "closed". Now, about PRs, a big chunk of the PRs open are just translations. I can't merge them until I get 2 approving reviews from native speakers. So they just stay there for a while. And I can't force people to come and help reviewing translations for their language. Then, there are many PRs that I would have an easier time re-implementing them myself than updating the code from the PR, maybe they add extra things not relevant to the current PR, or maybe they implement it in a way inconsistent with the rest of the code, etc. But I try to put an effort into updating the original PR instead of just discarding and re-writing. That also makes the process a bit slower. ## Issues and PRs to handle It's true I do have a bunch of issues and PRs to review across the projects (not just in FastAPI). But as I personally review and in most cases fine-tune and update each one of the PRs (if you check the history, almost no PR is directly merged, most of them require updates) it's taking me a bit to handle them all, but I'm on it. For the same reason, I can't just give permissions to others to simply merge PRs. ... I would probably give permissions to others (and I have done it in the past), after several non-trivial PRs that don't need any change from me. But that doesn't happen frequently. And still, even after some trusted approvals, I would try to review each PR myself before merging. ... This also isn’t happening. There are multiple open PRs that, without input from you detailing why they’re not ready to be merged, can only be considered high quality and merge-able, but have gone stale now because of the lack of aforementioned input. I get that you only want the best for your project, but with workflows like this, those PRs will never come. … I specifically want to focus on one pain point I currently have with FastAPI and its development: **optics**. I am not the most experienced developer, but I think a key component for any new project to take off is community sentiment. More specifically, it needs to viewed favourably by the community of developers that may eventually use the project. … Presumably these responders have viewed the GH page some time before, saw the overwhelming amount of issues and open PRs, and thought "oh well." Even if they were more critical at assessing the project they would notice things like: - infrequent merges - non-shrinking amount of PRs and issues - a barrage of new issues that are not even tagged