🙏 Find maintainers for FastAPI

First Check

• I added a very descriptive title to this issue.
• I used the GitHub search to find a similar issue and didn’t find it.
• I searched the FastAPI documentation, with the integrated search.
• I already searched in Google “How to X in FastAPI” and didn’t find any information.
• I already read and followed all the tutorial in the docs and didn’t find an answer.
• I already checked if it is not related to FastAPI but to Pydantic.
• I already checked if it is not related to FastAPI but to Swagger UI.
• I already checked if it is not related to FastAPI but to ReDoc.

Commit to Help

• I commit to help with one of those options 👆

Description

At the moment, all contributions to the FastAPI are made with @tiangolo (directly or through a PR review).

@tiangolo is doing a great job 💪, but fast developing project with great community like FastAPI demand much more time.
(It can be seen by the number of open issues and pull request)

Wanted Solution

Suggestion is to find several active community members and add them to the repository maintainers, as other projects (e.g. Flask and Django) do. 👨‍👩‍👧‍👦

This will help the development of the project and make the atmosphere for third-party contributors much more pleasant. 👾

Hope @tiangolo will consider this possibility

upd: discussion on this #3970

Wanted Code

from fastapi.community import active_members  

active_members.make_maintainers()

[tiangolo]

Hey! Thanks a lot for your interest.

Numbers

Let’s start with the numbers. I think you might be evaluating the number of issues and PRs with a different/biased point of view, here’s how.

Most of the issues are actually questions, and not bugs. And I use issues for questions because those allow imposing a bit of structure that can help users, me, and any of you here that also help. Additional to that, I don’t close issues once I or someone answers them, I feel that would be a bit rude (although maybe practical). I wait for the original poster to close them or I mark them to be closed later by a bot. Many of those questions are already answered and I haven’t had the time to mark/close them. But that’s what counts for the biggest chunk of the “issues open”. Also, some of the issues are just a place to handle some admin, for example, there’s an issue for each one of the languages being translated, and I wrote a bot that comments there to let participants to know there’s a new translation to review. 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. An important part of what has worked with FastAPI is that I have personally and very carefully handled it all, the best way I can. I can’t renounce to that now, at least not yet, and risk the codebase quality. 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.

Short Term Future

I even changed my working structure to optimize for more open source. I didn’t get the chance to work as much as I hoped for last year. I’m finishing a very large migration to FastAPI. This will also result in documentation around that process and how to handle compatibility with other frameworks and async/sync code. But I’m already arranging to compensate it this year soon that I finish that migration, and I’ll spend a lot of my working time this next quarter or two on FastAPI and friends.

During this time, I’ll also get the chance to see many contributions from others, and who knows, maybe I’ll feel more confident about giving extra permissions to some others.

Conversations like this one

Sadly, new issues and new discussions like this one asking why the other issues are not solved, don’t really help, as they just add another issue for me to read and take care of.

It also doesn’t help to comment or send me private messages or emails telling me to handle one specific issue. That becomes another message I have to handle on top of the thousands I receive from GitHub notifications for issues and PRs.

The same way, asking me to find new maintainers doesn’t really help me, because it just becomes another task you are asking me to carry out. It’s also not something that I can myself go out and find. I wouldn’t go and ask people to come and help for free, while at the same time I have never seen their work, in particular here, or I have seen only very little. It’s also not a matter of people simply volunteering to be maintainers if they have never contributed a non-trivial PR (or very few). None of those options are really enough for me to give them permissions.

But again, as I get the chance to review PRs, maybe I’ll find some active contributors with impeccable code and reviews that I would feel confident about giving them more access.

Recent Work

I’m prioritizing the work that can have the most impact.

Recently I was helping a bit with AnyIO and Trio, as AnyIO is used underneath by FastAPI (and it requires double compatibility with asyncio and Trio) and all that could end up used by you and your projects, even if you didn’t know about it. That’s not even visible in my projects, but you would still benefit from that work. For example, helping fix support for contextvars when executing synchronous tasks in a thread worker from an async context. You might end up needing all that in your projects, even without knowing, because it could be used by third party libraries you use. And these improvements make sure everything will simply work correctly underneath without you having to worry too much about it.

I was also working on a couple of small things for Pydantic, that would be used by SQLModel and FastAPI.

Before that, I released SQLModel, as I had the code, the ideas, and everything mostly ready, and people seemed to be needing something like it and no one was able to make it, so I spent the time to finish a first version that people could start exploring, before jumping to the next most impactful thing to do.

In the same way, I just released Asyncer a couple of days ago, to help the projects that need to work with concurrent code and that need to mix async and sync code, which I would think is a very strong use case for FastAPI.

Roadmap

I have several things that I want to work on, but my roadmap is flexible, as while working on one thing I could end up finding that there’s something with high impact that I could do, and if it’s worth it, I might just do that instead of a previously fixed plan that was made based on suppositions.

I currently don’t have investors or similar, so I don’t have to force myself to meet some product or marketing deadlines, or to figure out how to monetize something, etc. I can focus on whatever seems like what would have the most impact. Even if that means working on a third party open source library that isn’t even mine, but still feels like the right thing to do. I can do that now. That’s also why the roadmap is not very fixed.

As an example, I want it to be easier for people to work with async code. To run concurrent tasks, to be able to mix sync code with async code but reducing all the confusion around threads, thread workers, event loops, contextvars, thread locals, etc. That includes a lot of documentation I want to write. And it also ended up including building Asyncer, to be able to have a good developer experience with autocompletion, inline type errors, etc.

All that work on Asyncer started as PRs to Trio and AnyIO, and then in Asyncer itself, which is this tiny library to let me (and you if you want) use that API design, while those PRs are evaluated in Trio and AnyIO themselves. But the realization that it would make sense to make it its own tiny library, even if temporary, was last month, and then I finished it (almost all of it) during the break.

All that to say that I feel it’s an example of the benefits of my flexible roadmap and focusing on the resulting impact.

Come and Help me Maintain

The word “maintain” and “maintainer” probably means different things to each one of you, and each one of you probably measures it in different ways.

If you want to see faster progress, there are several ways to help, they are all documented here: https://fastapi.tiangolo.com/help-fastapi/

One of the things that consume time the most for a maintainer is handling issues created by others.

Many issues are incomplete questions. If you can go and check them, and if you can write a simple, minimal, self-contained example that shows the actual issue (or shows how to solve the user’s question), that’s normally the biggest chunk of time and you would be saving me from doing it myself. Then, you would be maintaining FastAPI. If it’s actually a bug, I can probably reuse your example as a test case, and that’s probably the biggest part of the work.

If you go and help them and they close those issues, that’s a lot of minutes (in some cases hours) that you save me, and that I can then dedicate to review the other issues and PRs. That’s work that a maintainer has to do. Wanna do it? I would be most grateful! Any of you can do it.

You can also review PRs yourself. But have in mind that adding a comment of “I have this problem too, merge this soon” doesn’t really help if you are not really reviewing the code, trying it in your project, and confirming that it indeed solves your use case. And if you did all that, please mention it.

In some way, here’s me asking you all to be maintainers for FastAPI.

FastAPI People

A lot of this work is already done by a bunch of people. Not many, but a few very dedicated and helpful volunteer people.

For example, @Kludex is one of the most helpful people here, always helping others, and always with a supportive and friendly attitude.

That’s why I created FastAPI People, and the FastAPI Experts. Those are the people that have helped maintain FastAPI, helping others with their questions: https://fastapi.tiangolo.com/fastapi-people/#experts

Do you have open issues? Go check it. Are they solved? Then please close them. Help me maintain this.

On the other hand, overly critical, aggressive, and demanding comments like those from @kevr, @stephane, @bratao only drain me, make me sad, and take out the energy I should be spending in working on this instead of arguing. At the same time, none of those users show up in FastAPI People, which means that none of them are helping FastAPI, helping maintain it, answering questions in issues, reviewing PRs, etc.

But for the rest of you, thanks a lot for your support and understanding. 🙇

[peterHoburg]

100% this. To stay at the level of Flask and Django, there needs to be a team of core maintainers. We can’t just rely on a single person.

FastAPI being a single maintainer project is a big reason some companies don’t want to start experimenting with it/using it.