python / python/devguide

Reviving / Carrying Forward PRs

Đang mở
#731 6 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

topic-pull requests type-feature
Ngôn ngữ chính
Python
Star
2.1k
Fork
1k
Merge trung bình
2 ngày 12 giờ
Pull request đã merge (30 ngày)
12

Mô tả

The Problem: Abandoned PRs

I am wondering about whether it is helpful for contributors to help move forward pull requests where the original contributor seems to have lost momentum for whatever reason. For example, I found bpo-19217 and PR-41203. There had been a long discussion and extensive review on the PR, but the original contributor stopped just short of making some final changes needed for merging. Of course, open source contributors have no obligation to continue working on a pull request, and the review process can definitely be challenging. At the same time, I notice so much core developer time being sunk into pull requests that never land. Some for good reason, but others because the original contributor just can't keep following up.

When I came across this issue, I went ahead and merged the original contributor's changes into a fresh branch on my fork, and did the additional work needed to create a branch ready for merge and to close the bpo, but I stopped short of opening a pull request because I didn't know what the procedure was and I definitely didn't want to step on the original contributor's toes. My changes can be viewed here.

Anyway, I am wondering what we think about this situation. Is there a role for contributors to help push forward pull requests that have lost steam? How can we make sure that both committers are equally recognized for their contribution? Pesumably only one can end up in the commit log, otherwise there will be unstable commits in cpython:main. In an ideal world, this workflow wouldn't be necessary, but I notice that there is so much great work lingering in 80%-complete github pull requests. This also wastes a ton of core dev time, because they review things that don't end up landing when the original contributor can't keep following through.

Role of the Dev Guide

I think that the dev guide can help here by establishing guidelines and procedures for people to do this type of work. For example, this chapter of the dev guide could:

  • Establish a procedure for "passing the torch"
    • After n number of days of no response from the original contributor, it's fair game for another contributor to merge changes into their own branch and start carrying the issue forward
    • Or, after n number of days, a new contributor can request to take over with a comment on the bpo or PR. The original contributor has n additional days to respond, before it is ok for the new contributor to finish their work.
  • Include a tutorial for how to take over:
git remote add original-contributor git@github.com/<other-contributor>/cpython
git merge other/<bpo-####>
  • Explain how both contributors will receive credit.

Hướng dẫn đóng góp

Mở hướng dẫn đóng góp

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Hướng nghiên cứu

Bắt đầu bằng việc xem lại chương Dev Guide được tham chiếu trong issue và ví dụ được liên kết về bpo-19217 và PR-41203. Ghi lại quy trình bàn giao, hướng dẫn tiếp quản và hướng dẫn về việc ghi nhận đóng góp của contributor, bao gồm các khoảng thời gian phản hồi được đề xuất; hoàn tất khi tài liệu hướng dẫn liên quan giải thích rõ workflow này.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Đánh giá

Công nghệ
git, github
Lĩnh vực
developer-experience, documentation
Loại issue
Tài liệu
Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức độ hoạt động
Đình trệ
Độ rõ ràng
Cần làm rõ
Mức phù hợp với người mới
30/100

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.