-# Help FastAPI - Get Help { #help-fastapi-get-help }
+# Help { #help }
-Do you like **FastAPI**?
+Would you like to help FastAPI or get help about FastAPI?
-Would you like to help FastAPI, other users, and the author?
-
-Or would you like to get help with **FastAPI**?
-
-There are very simple ways to help (several involve just one or two clicks).
-
-And there are several ways to get help too.
+There are very simple ways to help and get help.
## Subscribe to the newsletter { #subscribe-to-the-newsletter }
* Breaking changes π¨
* Tips and tricks β
-## Follow FastAPI on X (Twitter) { #follow-fastapi-on-x-twitter }
+## Follow FastAPI online { #follow-fastapi-online }
-[Follow @fastapi on **X (Twitter)**](https://x.com/fastapi) to get the latest news about **FastAPI**. π¦
+You can follow **FastAPI** online in several places:
+
+* [@fastapi on **X / Twitter**](https://x.com/fastapi)
+* [@fastapi.tiangolo.com on **Bluesky**](https://bsky.app/profile/fastapi.tiangolo.com)
+* [FastAPI on **LinkedIn**](https://www.linkedin.com/company/fastapi/)
## Star **FastAPI** in GitHub { #star-fastapi-in-github }
By doing it, you will receive notifications (in your email) whenever there's a new release (a new version) of **FastAPI** with bug fixes and new features.
-## Connect with the author { #connect-with-the-author }
-
-You can connect with [me (SebastiΓ‘n RamΓrez / `tiangolo`)](https://tiangolo.com), the author.
-
-You can:
-
-* [Follow me on **GitHub**](https://github.com/tiangolo).
- * See other Open Source projects I have created that could help you.
- * Follow me to see when I create a new Open Source project.
-* [Follow me on **X (Twitter)**](https://x.com/tiangolo) or [Mastodon](https://fosstodon.org/@tiangolo).
- * Tell me how you use FastAPI (I love to hear that).
- * Hear when I make announcements or release new tools.
- * You can also [follow @fastapi on X (Twitter)](https://x.com/fastapi) (a separate account).
-* [Follow me on **LinkedIn**](https://www.linkedin.com/in/tiangolo/).
- * Hear when I make announcements or release new tools (although I use X (Twitter) more often π€·ββ).
-* Read what I write (or follow me) on [**Dev.to**](https://dev.to/tiangolo) or [**Medium**](https://medium.com/@tiangolo).
- * Read other ideas, articles, and read about tools I have created.
- * Follow me to read when I publish something new.
-
-## Tweet about **FastAPI** { #tweet-about-fastapi }
-
-[Tweet about **FastAPI**](https://x.com/compose/tweet?text=I'm loving @fastapi because... https://github.com/fastapi/fastapi) and let me and others know why you like it. π
-
-I love to hear about how **FastAPI** is being used, what you have liked in it, in which project/company are you using it, etc.
+## Follow the author { #follow-the-author }
-## Vote for FastAPI { #vote-for-fastapi }
+You can follow [me (SebastiΓ‘n RamΓrez / `tiangolo`)](https://tiangolo.com), the author in a few places, to hear when I have news to share about FastAPI and friends:
-* [Vote for **FastAPI** in Slant](https://www.slant.co/options/34241/~fastapi-review).
-* [Vote for **FastAPI** in AlternativeTo](https://alternativeto.net/software/fastapi/about/).
-* [Say you use **FastAPI** on StackShare](https://stackshare.io/pypi-fastapi).
+* [@tiangolo on **GitHub**](https://github.com/tiangolo).
+* [@tiangolo on **X (Twitter)**](https://x.com/tiangolo)
+* [@tiangolo.com on **Bluesky**](https://bsky.app/profile/tiangolo.com)
+* [@tiangolo on **LinkedIn**](https://www.linkedin.com/in/tiangolo/).
## Help others with questions in GitHub { #help-others-with-questions-in-github }
-You can try and help others with their questions in:
-
-* [GitHub Discussions](https://github.com/fastapi/fastapi/discussions/categories/questions?discussions_q=category%3AQuestions+is%3Aunanswered)
-* [GitHub Issues](https://github.com/fastapi/fastapi/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3Aquestion+-label%3Aanswered+)
+You can try and help others with their questions in [GitHub Discussions](https://github.com/fastapi/fastapi/discussions/categories/questions?discussions_q=category%3AQuestions+is%3Aunanswered).
In many cases you might already know the answer for those questions. π€
If you are helping a lot of people with their questions, you will become an official [FastAPI Expert](fastapi-people.md#fastapi-experts). π
-Just remember, the most important point is: try to be kind. People come with their frustrations and in many cases don't ask in the best way, but try as best as you can to be kind. π€
-
-The idea is for the **FastAPI** community to be kind and welcoming. At the same time, don't accept bullying or disrespectful behavior towards others. We have to take care of each other.
-
----
-
-Here's how to help others with questions (in discussions or issues):
-
-### Understand the question { #understand-the-question }
-
-* Check if you can understand what is the **purpose** and use case of the person asking.
-
-* Then check if the question (the vast majority are questions) is **clear**.
-
-* In many cases the question asked is about an imaginary solution from the user, but there might be a **better** one. If you can understand the problem and use case better, you might be able to suggest a better **alternative solution**.
-
-* If you can't understand the question, ask for more **details**.
-
-### Reproduce the problem { #reproduce-the-problem }
+Just remember, the most important point is: try to be kind. π€
-For most of the cases and most of the questions there's something related to the person's **original code**.
+### How to Help { #how-to-help }
-In many cases they will only copy a fragment of the code, but that's not enough to **reproduce the problem**.
-
-* You can ask them to provide a [minimal, reproducible, example](https://stackoverflow.com/help/minimal-reproducible-example), that you can **copy-paste** and run locally to see the same error or behavior they are seeing, or to understand their use case better.
-
-* If you are feeling too generous, you can try to **create an example** like that yourself, just based on the description of the problem. Just keep in mind that this might take a lot of time and it might be better to ask them to clarify the problem first.
-
-### Suggest solutions { #suggest-solutions }
-
-* After being able to understand the question, you can give them a possible **answer**.
-
-* In many cases, it's better to understand their **underlying problem or use case**, because there might be a better way to solve it than what they are trying to do.
-
-### Ask to close { #ask-to-close }
-
-If they reply, there's a high chance you would have solved their problem, congrats, **you're a hero**! π¦Έ
-
-* Now, if that solved their problem, you can ask them to:
-
- * In GitHub Discussions: mark the comment as the **answer**.
- * In GitHub Issues: **close** the issue.
-
-## Watch the GitHub repository { #watch-the-github-repository }
-
-You can "watch" FastAPI in GitHub (clicking the "watch" button at the top right): [https://github.com/fastapi/fastapi](https://github.com/fastapi/fastapi). π
-
-If you select "Watching" instead of "Releases only" you will receive notifications when someone creates a new issue or question. You can also specify that you only want to be notified about new issues, or discussions, or PRs, etc.
-
-Then you can try and help them solve those questions.
+Follow the [guide on how to help](https://tiangolo.com/open-source/help/#help-others-with-questions-in-github) here.
## Ask Questions { #ask-questions }
* Ask a **question** or ask about a **problem**.
* Suggest a new **feature**.
-**Note**: if you do it, then I'm going to ask you to also help others. π
-
-## Review Pull Requests { #review-pull-requests }
-
-You can help me review pull requests from others.
-
-Again, please try your best to be kind. π€
-
----
-
-Here's what to keep in mind and how to review a pull request:
-
-### Understand the problem { #understand-the-problem }
-
-* First, make sure you **understand the problem** that the pull request is trying to solve. It might have a longer discussion in a GitHub Discussion or issue.
-
-* There's also a good chance that the pull request is not actually needed because the problem can be solved in a **different way**. Then you can suggest or ask about that.
-
-### Don't worry about style { #dont-worry-about-style }
-
-* Don't worry too much about things like commit message styles, I will squash and merge customizing the commit manually.
-
-* Also don't worry about style rules, there are already automatized tools checking that.
-
-And if there's any other style or consistency need, I'll ask directly for that, or I'll add commits on top with the needed changes.
-
-### Check the code { #check-the-code }
-
-* Check and read the code, see if it makes sense, **run it locally** and see if it actually solves the problem.
-
-* Then **comment** saying that you did that, that's how I will know you really checked it.
-
-/// note
-
-Unfortunately, I can't simply trust PRs that just have several approvals.
-
-Several times it has happened that there are PRs with 3, 5 or more approvals, probably because the description is appealing, but when I check the PRs, they are actually broken, have a bug, or don't solve the problem they claim to solve. π
-
-So, it's really important that you actually read and run the code, and let me know in the comments that you did. π€
-
-///
-
-* If the PR can be simplified in a way, you can ask for that, but there's no need to be too picky, there might be a lot of subjective points of view (and I will have my own as well π), so it's better if you can focus on the fundamental things.
-
-### Tests { #tests }
-
-* Help me check that the PR has **tests**.
-
-* Check that the tests **fail** before the PR. π¨
-
-* Then check that the tests **pass** after the PR. β
-
-* Many PRs don't have tests, you can **remind** them to add tests, or you can even **suggest** some tests yourself. That's one of the things that consume most time and you can help a lot with that.
-
-* Then also comment what you tried, that way I'll know that you checked it. π€
-
-## Create a Pull Request { #create-a-pull-request }
-
-You can [contribute](contributing.md) to the source code with Pull Requests, for example:
-
-* To fix a typo you found on the documentation.
-* To share an article, video, or podcast you created or found about FastAPI by [editing this file](https://github.com/fastapi/fastapi/edit/master/docs/en/data/external_links.yml).
- * Make sure you add your link to the start of the corresponding section.
-* To help [translate the documentation](contributing.md#translations) to your language.
- * You can also help to review the translations created by others.
-* To propose new documentation sections.
-* To fix an existing issue/bug.
- * Make sure to add tests.
-* To add a new feature.
- * Make sure to add tests.
- * Make sure to add documentation if it's relevant.
-
-Note that PRs from non-team members are not allowed to modify `pyproject.toml` or `uv.lock`, to prevent supply chain risk.
-If you would like to add a new dependency, create a new [Discussion](https://github.com/fastapi/fastapi/discussions/categories/questions) to explain why.
-
-## Help Maintain FastAPI { #help-maintain-fastapi }
-
-Help me maintain **FastAPI**! π€
-
-There's a lot of work to do, and for most of it, **YOU** can do it.
-
-The main tasks that you can do right now are:
-
-* [Help others with questions in GitHub](#help-others-with-questions-in-github) (see the section above).
-* [Review Pull Requests](#review-pull-requests) (see the section above).
-
-Those two tasks are what **consume time the most**. That's the main work of maintaining FastAPI.
-
-If you can help me with that, **you are helping me maintain FastAPI** and making sure it keeps **advancing faster and better**. π
-
-## Join the chat { #join-the-chat }
+## Join the Chat { #join-the-chat }
Join the π₯ [Discord chat server](https://discord.gg/VQjSZaeJmf) π₯ and hang out with others in the FastAPI community.
/// tip
-For questions, ask them in [GitHub Discussions](https://github.com/fastapi/fastapi/discussions/new?category=questions), there's a much better chance you will receive help by the [FastAPI Experts](fastapi-people.md#fastapi-experts).
+For questions, ask them in GitHub Discussions, there's a much better chance you will receive help.
Use the chat only for other general conversations.
///
-### Don't use the chat for questions { #dont-use-the-chat-for-questions }
+### Don't use the Chat for Questions { #dont-use-the-chat-for-questions }
Keep in mind that as chats allow more "free conversation", it's easy to ask questions that are too general and more difficult to answer, so, you might not receive answers.
-In GitHub, the template will guide you to write the right question so that you can more easily get a good answer, or even solve the problem yourself even before asking. And in GitHub I can make sure I always answer everything, even if it takes some time. I can't personally do that with the chat systems. π
-
-Conversations in the chat systems are also not as easily searchable as in GitHub, so questions and answers might get lost in the conversation. And only the ones in GitHub count to become a [FastAPI Expert](fastapi-people.md#fastapi-experts), so you will most probably receive more attention in GitHub.
-
-On the other side, there are thousands of users in the chat systems, so there's a high chance you'll find someone to talk to there, almost all the time. π
-
-## Sponsor the author { #sponsor-the-author }
-
-If your **product/company** depends on or is related to **FastAPI** and you want to reach its users, you can sponsor the author (me) through [GitHub sponsors](https://github.com/sponsors/tiangolo). Depending on the tier, you could get some extra benefits, like a badge in the docs. π
-
----
+In GitHub, the template will guide you to write the right question so that you can more easily get a good answer, or even solve the problem yourself even before asking.
-Thanks! π
+Conversations in the chat systems are also not as easily searchable as in GitHub, they get lost.
+++ /dev/null
-# Repository Management Tasks
-
-These are the tasks that can be performed to manage the FastAPI repository by [team members](./fastapi-people.md#team).
-
-/// tip
-
-This section is useful only to a handful of people, team members with permissions to manage the repository. You can probably skip it. π
-
-///
-
-...so, you are a [team member of FastAPI](./fastapi-people.md#team)? Wow, you are so cool! π
-
-You can help with everything on [Help FastAPI - Get Help](./help-fastapi.md) the same ways as external contributors. But additionally, there are some tasks that only you (as part of the team) can perform.
-
-Here are the general instructions for the tasks you can perform.
-
-Thanks a lot for your help. π
-
-## Be Nice
-
-First of all, be nice. π
-
-You probably are super nice if you were added to the team, but it's worth mentioning it. π€
-
-### When Things are Difficult
-
-When things are great, everything is easier, so that doesn't need much instructions. But when things are difficult, here are some guidelines.
-
-Try to find the good side. In general, if people are not being unfriendly, try to thank their effort and interest, even if you disagree with the main subject (discussion, PR), just thank them for being interested in the project, or for having dedicated some time to try to do something.
-
-It's difficult to convey emotion in text, use emojis to help. π
-
-In discussions and PRs, in many cases, people bring their frustration and show it without filter, in many cases exaggerating, complaining, being entitled, etc. That's really not nice, and when it happens, it lowers our priority to solve their problems. But still, try to breath, and be gentle with your answers.
-
-Try to avoid using bitter sarcasm or potentially passive-aggressive comments. If something is wrong, it's better to be direct (try to be gentle) than sarcastic.
-
-Try to be as specific and objective as possible, avoid generalizations.
-
-For conversations that are more difficult, for example to reject a PR, you can ask me (@tiangolo) to handle it directly.
-
-## Edit PR Titles
-
-* Edit the PR title to start with an emoji from [gitmoji](https://gitmoji.dev/).
- * Use the emoji character, not the GitHub code. So, use `π` instead of `:bug:`. This is so that it shows up correctly outside of GitHub, for example in the release notes.
- * For translations use the `π` emoji ("globe with meridians").
-* Start the title with a verb. For example `Add`, `Refactor`, `Fix`, etc. This way the title will say the action that the PR does. Like `Add support for teleporting`, instead of `Teleporting wasn't working, so this PR fixes it`.
-* Edit the text of the PR title to start in "imperative", like giving an order. So, instead of `Adding support for teleporting` use `Add support for teleporting`.
-* Try to make the title descriptive about what it achieves. If it's a feature, try to describe it, for example `Add support for teleporting` instead of `Create TeleportAdapter class`.
-* Do not finish the title with a period (`.`).
-* When the PR is for a translation, start with the `π` and then `Add {language} translation for` and then the translated file path. For example:
-
-```Markdown
-π Add Spanish translation for `docs/es/docs/teleporting.md`
-```
-
-Once the PR is merged, a GitHub Action ([latest-changes](https://github.com/tiangolo/latest-changes)) will use the PR title to update the latest changes automatically.
-
-So, having a nice PR title will not only look nice in GitHub, but also in the release notes. π
-
-## Add Labels to PRs
-
-The same GitHub Action [latest-changes](https://github.com/tiangolo/latest-changes) uses one label in the PR to decide the section in the release notes to put this PR in.
-
-Make sure you use a supported label from the [latest-changes list of labels](https://github.com/tiangolo/latest-changes#using-labels):
-
-* `breaking`: Breaking Changes
- * Existing code will break if they update the version without changing their code. This rarely happens, so this label is not frequently used.
-* `security`: Security Fixes
- * This is for security fixes, like vulnerabilities. It would almost never be used.
-* `feature`: Features
- * New features, adding support for things that didn't exist before.
-* `bug`: Fixes
- * Something that was supported didn't work, and this fixes it. There are many PRs that claim to be bug fixes because the user is doing something in an unexpected way that is not supported, but they considered it what should be supported by default. Many of these are actually features or refactors. But in some cases there's an actual bug.
-* `refactor`: Refactors
- * This is normally for changes to the internal code that don't change the behavior. Normally it improves maintainability, or enables future features, etc.
-* `upgrade`: Upgrades
- * This is for upgrades to direct dependencies from the project, or extra optional dependencies, normally in `pyproject.toml`. So, things that would affect final users, they would end up receiving the upgrade in their code base once they update. But this is not for upgrades to internal dependencies used for development, testing, docs, etc. Those internal dependencies or GitHub Action versions should be marked as `internal`, not `upgrade`.
-* `docs`: Docs
- * Changes in docs. This includes updating the docs, fixing typos. But it doesn't include changes to translations.
- * You can normally quickly detect it by going to the "Files changed" tab in the PR and checking if the updated file(s) starts with `docs/en/docs`. The original version of the docs is always in English, so in `docs/en/docs`.
-* `lang-all`: Translations
- * Use this for translations. You can normally quickly detect it by going to the "Files changed" tab in the PR and checking if the updated file(s) starts with `docs/{some lang}/docs` but not `docs/en/docs`. For example, `docs/es/docs`.
-* `internal`: Internal
- * Use this for changes that only affect how the repo is managed. For example upgrades to internal dependencies, changes in GitHub Actions or scripts, etc.
-
-/// tip
-
-Some tools like Dependabot, will add some labels, like `dependencies`, but have in mind that this label is not used by the `latest-changes` GitHub Action, so it won't be used in the release notes. Please make sure one of the labels above is added.
-
-///
-
-## Add Labels to Translation PRs
-
-When there's a PR for a translation, apart from adding the `lang-all` label, also add a label for the language.
-
-There will be a label for each language using the language code, like `lang-{lang code}`, for example, `lang-es` for Spanish, `lang-fr` for French, etc.
-
-* Add the specific language label.
-* Add the label `awaiting-review`.
-
-The label `awaiting-review` is special, only used for translations. A GitHub Action will detect it, then it will read the language label, and it will update the GitHub Discussions managing the translations for that language to notify people that there's a new translation to review.
-
-Once a native speaker comes, reviews the PR, and approves it, the GitHub Action will come and remove the `awaiting-review` label, and add the `approved-1` label.
-
-This way, we can notice when there are new translations ready, because they have the `approved-1` label.
-
-## Merge Translation PRs
-
-Translations are generated automatically with LLMs and scripts.
-
-There's one GitHub Action that can be manually run to add or update translations for a language: [`translate.yml`](https://github.com/fastapi/fastapi/actions/workflows/translate.yml).
-
-For these language translation PRs, confirm that:
-
-* The PR was automated (authored by @tiangolo), not made by another user.
-* It has the labels `lang-all` and `lang-{lang code}`.
-
-For PRs that update language-specific LLM prompts, confirm that:
-
-* The PR has the labels `lang-all` and `lang-{lang code}`.
-* It is approved by at least one native speaker.
-* In some cases you might need to translate several pages with new prompt to make sure it works as expected.
-
-If the PR meets the above conditions, you can merge it. π
-
-## Review PRs
-
-* If a PR doesn't explain what it does or why, if it seems like it could be useful, ask for more information. Otherwise, feel free to close it.
-
-* If a PR seems to be spam, meaningless, only to change statistics (to appear as "contributor") or similar, you can simply mark it as `invalid`, and it will be automatically closed.
-
-* If a PR seems to be AI generated, and seems like reviewing it would take more time from you than the time it took to write the prompt, mark it as `maybe-ai`, and it will be automatically closed.
-
-* A PR should have a specific use case that it is solving.
-
-* If the PR is for a feature, it should have docs.
- * Unless it's a feature we want to discourage, like support for a corner case that we don't want users to use.
-* The docs should include a source example file, not write Python directly in Markdown.
-* If the source example(s) file can have different syntax for different Python versions, there should be different versions of the file, and they should be shown in tabs in the docs.
-* There should be tests testing the source example.
-* Before the PR is applied, the new tests should fail.
-* After applying the PR, the new tests should pass.
-* Coverage should stay at 100%.
-* If you see the PR makes sense, or we discussed it and considered it should be accepted, you can add commits on top of the PR to tweak it, to add docs, tests, format, refactor, remove extra files, etc.
-* Feel free to comment in the PR to ask for more information, to suggest changes, etc.
-* Once you think the PR is ready, move it in the internal GitHub project for me to review it.
-
-## FastAPI People PRs
-
-Every month, a GitHub Action updates the FastAPI People data. Those PRs look like this one: [π₯ Update FastAPI People](https://github.com/fastapi/fastapi/pull/11669).
-
-If the tests are passing, you can merge it right away.
-
-## Dependabot PRs
-
-Dependabot will create PRs to update dependencies for several things, and those PRs all look similar, but some are way more delicate than others.
-
-* If the PR is for a direct dependency, so, Dependabot is modifying `pyproject.toml` in the main dependencies, **don't merge it**. π± Let me check it first. There's a good chance that some additional tweaks or updates are needed.
-* If the PR updates one of the internal dependencies, for example the group `dev` in `pyproject.toml`, or GitHub Action versions, if the tests are passing, the release notes (shown in a summary in the PR) don't show any obvious potential breaking change, you can merge it. π
-
-## Mark GitHub Discussions Answers
-
-When a question in GitHub Discussions has been answered, mark the answer by clicking "Mark as answer".
-
-You can filter discussions by [`Questions` that are `Unanswered`](https://github.com/tiangolo/fastapi/discussions/categories/questions?discussions_q=category:Questions+is:open+is:unanswered).
projects / thirdparty / fastapi / fastapi.git / commitdiff
