Split Backporting into "policy" and "guide"

Open
#1,831 1 comment 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
58/100
Issue type
Documentation
Clarity
Mostly clear
Activity status
Quiet
Tech stack
git
Domain
documentation

Research direction

Review the current Backporting material and the Development Cycle page, which the issue identifies as a possible home for policy. Separate the required workflow—main first, the [3.x] prefix, and what changes are backported—from the practical guide covering tags, bots, cherry-picker, and Git commands; done means both sections clearly cover their respective topics.

Written by the indexing model from the issue text.

Description

topic-dev process topic-pull requests type-refactor

As a follow-up to #1819:

It would be great to have two sections for Backporting: a policy document to explain what's required (main first, backport with the [3.x] prefix, what kinds of changes get backported where -- perhaps the Development Cycle page is a good place for this), and a guide for the practicalities & automation (tags, bots, cherry-picker, Git commands).

Dominant language
Python
Stars
2.1k
Forks
1k
Avg merge
2d 12h
Merged PRs (30d)
12

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from python/devguide

All issues in python/devguide

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.