name: 'Close stale PRs'
on:
  schedule:
    # Execute every hour at xx:05 to avoid conflicts with other workflows
    - cron: '5 * * * *'

permissions: {}

jobs:
  stale:
    permissions:
      pull-requests: write

    runs-on: ubuntu-latest
    steps:
      - uses: actions/stale@v10
        with:
          operations-per-run: 50
          ascending: true
          exempt-all-milestones: true

						}
					}
				}
			}
		}
		prs := peerResults[local]
		if prs.Err == "" {
			if err = commitBinary(); err != nil {
				prs.Err = err.Error()
			}
			peerResults[local] = prs
		}
	}

	prs, ok := peerResults[local]
	if ok {
		prs.WaitingDrives = waitingDrivesNode()
		peerResults[local] = prs
	}

	if globalIsDistErasure {

Making and Submitting Changes
--------------

We accept Pull Requests via GitHub. The [developer mailing list][dev-ml-list] is the
main channel of communication for contributors.  
There are some guidelines which will make applying PRs easier for us:
+ Create a topic branch from where you want to base your work (this is usually the master branch).
  Push your changes to a topic branch in your fork of the repository.
+ Make commits of logical units.

* [Sign off your commits](https://git-scm.com/docs/git-commit#Documentation/git-commit.txt---signoff) to indicate that you agree to the terms of [Developer Certificate of Origin](https://developercertificate.org/). We can only accept PRs that have all commits signed off.
* Keep commits discrete. Avoid including multiple unrelated changes in a single commit.

            + f"\n\nIt uses the prompt file https://github.com/fastapi/fastapi/blob/master/docs/{language}/llm-prompt.md."
            + "\n\nIn most cases, it's better to make PRs updating that file so that the LLM can do a better job generating the translations than suggesting changes in this PR."
        )
        pr = gh_repo.create_pull(

    airtime before a decision is made regarding whether they are to be migrated
    to the core.
*   As every PR requires several CPU/GPU hours of CI testing, we discourage
    submitting PRs to fix one typo, one warning,etc. We recommend fixing the
    same issue at the file level at least (e.g.: fix all typos in a file, fix
    all compiler warnings in a file, etc.)
*   Tests should follow the

efforts, take the wrong approach to solving a problem, or solve a problem which
does not need solving. An up-front discussion often saves a good deal of wasted
time in these cases.

We normally immediately reject isolated PRs that only perform simple
refactorings or otherwise "tidy up" certain aspects of the code. We think the
benefits of this kind of change are very small, and in our experience it is not

/// info | Info

Leider kann ich PRs, nur weil sie von mehreren gutgeheißen wurden, nicht einfach vertrauen.

Es ist mehrmals passiert, dass es PRs mit drei, fünf oder mehr Zustimmungen gibt, wahrscheinlich weil die Beschreibung ansprechend ist, aber wenn ich die PRs überprüfe, sind sie tatsächlich fehlerhaft, haben einen Bug, oder lösen das Problem nicht, welches sie behaupten, zu lösen. 😅

/// info | Información

Desafortunadamente, no puedo simplemente confiar en PRs que solo tienen varias aprobaciones.

Varias veces ha sucedido que hay PRs con 3, 5 o más aprobaciones, probablemente porque la descripción es atractiva, pero cuando reviso los PRs, en realidad están rotos, tienen un bug, o no resuelven el problema que dicen resolver. 😅

/// info | Informação

Infelizmente, eu não posso simplesmente confiar em PRs que têm várias aprovações.

Já aconteceu várias vezes de haver PRs com 3, 5 ou mais aprovações, provavelmente porque a descrição é atraente, mas quando eu verifico os PRs, eles estão quebrados, têm um bug, ou não resolvem o problema que afirmam resolver. 😅