Tôi nên đóng góp như thế nào cho một dự án GitHub bị bỏ rơi (hầu hết)?


43

Gần đây tôi đã cố gắng tham gia cộng tác nguồn mở trong GitHub và đã gặp phải một tình huống mà tôi tò mò không biết cách nào được ưu tiên để tiến hành.

Khoảng một tháng trước, tôi đã tìm thấy một dự án trên GitHub cho một thư viện mà tôi đã sử dụng được một thời gian và trong đó tôi đã tìm thấy (và sửa) một vài lỗi.

Như một bước đột phá ban đầu vào sự hợp tác của GitHub, tôi đã tìm thấy repo dường như có khối lượng hoạt động gần đây cao nhất, đã sửa một lỗi, thêm các bài kiểm tra đơn vị, đẩy lên GitHub và đưa ra yêu cầu kéo. Trong vài giờ, người duy trì repo mà tôi rẽ nhánh đã chấp nhận PR và sáp nhập vào một vài PR khác từ những người khác cũng đang chờ đợi.

Được thúc đẩy bởi điều này, tôi đã sửa thêm ba lỗi mà tôi đã tìm thấy, mỗi lỗi trong một nhánh riêng của repo của riêng tôi và gửi một vấn đề và yêu cầu kéo riêng cho từng lỗi.

Đó chỉ là hơn một tháng trước, và các yêu cầu kéo đã được đặt ở đó, chưa được xử lý, kể từ đó. Người dùng có repo mà tôi đã rẽ nhánh dường như không hoạt động nhiều, chỉ thực hiện 7 lần đóng góp trên GitHub trong năm qua và repo đó đã không có bất kỳ cam kết nào kể từ yêu cầu kéo đầu tiên mà tôi đã thực hiện.

Vì vậy, câu hỏi của tôi:

Làm thế nào để một người tiến hành trong tình huống này? Lý tưởng nhất, tôi muốn tránh tạo ra sự phân mảnh của thư viện bằng cách tắt và thực hiện một loạt các thay đổi trong repo của riêng tôi mà không được sáp nhập vào repo cha. Tuy nhiên, tôi muốn tiếp tục sửa lỗi và thêm các tính năng, nhưng nếu tôi hợp nhất mọi thứ vào nhánh chính của mình và căn cứ tất cả các bản sửa lỗi mới từ nhánh đó, thì nếu người duy trì repo mà tôi rẽ nhánh trở lại, tôi đã thắng Không thể chia tất cả các thay đổi thành các yêu cầu kéo riêng cho từng tính năng / sửa lỗi (Tôi đã đọc rằng các yêu cầu kéo thường là một yêu cầu kéo cho mỗi tính năng hoặc sửa lỗi).

Tôi có nên giữ một nhánh tương ứng với repo ban đầu, dựa trên tất cả các nhánh mới của tôi khỏi nhánh đó và sau đó giữ tất cả các cam kết được hợp nhất trong nhánh chính của tôi không? Có vẻ như điều đó sẽ để lại cho tôi cả tấn chi nhánh và một nhiệm vụ ngày càng nặng nề mỗi khi tôi cần hợp nhất những thay đổi mới vào chi nhánh chính của mình.

Cách điển hình mà người ta sẽ tiếp cận một tình huống như thế này là gì? Dường như khá phổ biến rằng một dự án sẽ bị bỏ rơi với những người đóng góp ban đầu không có mặt để xem xét các yêu cầu kéo mới. Đây có phải là một tình huống mà ai đó chỉ nên cầm lái và chạy với nó? Có vẻ như nó sẽ tạo ra sự phân mảnh nếu những người đóng góp ban đầu quay trở lại và muốn làm việc lại với dự án.


4
Khi bạn thấy câu hỏi này thú vị, bạn cũng có thể quan tâm đến đề xuất cho một trang web stackexchange mã nguồn mở mới .
Philipp

Muốn chia sẻ những gì phát sinh từ cuộc trò chuyện email chỉ dành cho chúng tôi những người xem tò mò? :)
nháy mắt

@winkbrace Cho đến nay, không có gì. Tôi chưa nhận được phản hồi, nhưng tôi chỉ gửi e-mail hai ngày trước. Tôi sẽ cho tất cả các bạn biết nếu một cái gì đó phát triển.
JLRishe

Câu trả lời:


39

Tôi chưa gặp tình huống này, nhưng đó là điều tôi sẽ thử:

Hãy thử liên hệ với chủ sở hữu

Có thể họ thực sự mất hứng thú, nhưng sẵn sàng chuyển giao dự án cho người khác, đặc biệt là một người đã thể hiện cam kết ân cần.

Nhưng có lẽ họ chỉ bận rộn với một cái gì đó khác (công việc, kỳ nghỉ, bệnh tật, các dự án khác) và không có thời gian để xử lý PR của bạn, nhưng dự định sẽ thực hiện sau.

Hoặc có thể họ đã thực sự dừng công việc trên dự án vĩnh viễn vì bất kỳ lý do gì.

Không cần hỏi, bạn sẽ không tìm thấy nó.

Liên lạc với cộng đồng

Chắc chắn có những người khác đã đóng góp, hoặc ít nhất là sử dụng dự án. Kiểm tra xem ai đã rẽ nhánh dự án (ngay cả khi họ không thực hiện bất kỳ thay đổi nào, họ vẫn có thể quan tâm khi thấy dự án này phát triển mạnh); kiểm tra xem ai đã báo cáo vấn đề, hoặc bình luận về chúng Có thể cũng có một cộng đồng bên ngoài GitHub, ví dụ như danh sách gửi thư, diễn đàn hoặc thành viên StackOverflow.

Tôi cuối cùng là bạn thực sự tiếp quản dự án, bạn có thể muốn hỗ trợ của họ. Và họ cần biết kho lưu trữ tổng thể mới ở đâu.

Tiếp tục thực hiện các yêu cầu kéo tốt

Điều này cho thấy cả chủ sở hữu và cộng đồng rằng bạn nghiêm túc với điều đó và hãy để họ đánh giá những đóng góp của bạn.


1
Cảm ơn bạn. Sau khi tìm kiếm thêm một chút, có vẻ như lời khuyên này tương tự như các hướng dẫn có sẵn cho loại tình huống này với các gói npm . Tôi vừa gửi e-mail cho chủ sở hữu và sẽ xem những gì anh / cô ấy trả lời.
JLRishe

Rất khó để tìm ai đó có khả năng phê duyệt PR cho một repo cụ thể khi "chủ sở hữu" của repo thực sự là một tổ chức có hàng tá người dùng.
chăn bò

15

Nếu chủ sở hữu của repo ban đầu không được tìm thấy ở bất cứ đâu và vắng mặt đáng kể, tôi sẽ xuất bản kho lưu trữ của riêng tôi dưới dạng một phiên bản khác của dự án.

Với điều này, bạn tiếp quản sự phát triển của thư viện và không để nó chết ở một góc mà không được cập nhật lại. Nếu chủ sở hữu ban đầu đã đóng repo, thế giới vẫn có thể sử dụng phiên bản rẽ nhánh.


1
Có, chỉ đơn giản forklà dự án và trong README.md, để lại một tài liệu tham khảo và "cảm ơn" cho chủ sở hữu ban đầu.
Jared Burrows

Cảm ơn câu trả lời của bạn (+1). Bạn chắc chắn làm cho một số điểm tốt. Cuối cùng tôi có thể dùng đến điều này, nhưng bây giờ, tôi sẽ làm theo lời khuyên của oefe và xem liệu tôi có thể liên lạc với chủ sở hữu của repo qua e-mail không.
JLRishe

Tất nhiên, đừng để kho lưu trữ rơi vào quên lãng. Rất nhiều mã tốt phải được ẩn ở đâu đó sâu trong Github vì chủ sở hữu ban đầu không còn nữa.
cllamach

Tôi đang ở trong một tình huống tương tự và có thể cần phải thực hiện tùy chọn này - chủ sở hữu ban đầu của dự án đã không phản hồi với các nỗ lực liên hệ lặp đi lặp lại. Có phải là giữ tên của dự án và tiếp tục tăng số phiên bản từ phiên bản chính thức cuối cùng? Tôi lo lắng rằng nếu tôi thay đổi tên, người dùng hiện tại của dự án sẽ khó tìm thấy hơn.
pericynthion 17/03/2015

1
Tôi cũng có thể ở trong tình huống đó. Nhưng dự án ban đầu đã được đăng ký với Bower. Giữ tên có nghĩa là phải yêu cầu tác giả ban đầu hủy đăng ký tên cho bạn hoặc liên hệ với những người bảo trì Bower và yêu cầu họ can thiệp. Mặc dù vậy, tôi không quan tâm lắm đến việc làm sau. Đổi tên có thể là lựa chọn tốt nhất.
Lawrence I. Siden

0

Vì hầu hết các dự án Nguồn mở và Miễn phí cỡ nhỏ đến trung bình hiện nay đều được lưu trữ trên github, gitlab hoặc tương tự, nên có thể tự động hóa một số quy trình , sử dụng API Web của chúng.

Giả sử repo ban đầu là https://github.com/someUserX/projectY/, quá trình có thể như thế này:

  1. ("thủ công") Liên hệ với tác giả gốc theo nhiều cách khác nhau, ít nhất là qua email người gửi git của anh ta và một vấn đề (nếu được bật).

    Trong trường hợp có sự cho phép nhận được hoặc không có phản hồi trong vài tuần, người ta có thể chạy một tập lệnh sẽ sử dụng API Web của máy chủ lưu trữ để thực hiện các bước như sau:

  2. tạo một tổ chức (GitHub) mới được gọi projectYvà trong đó rẽ nhánh repo ban đầu ->https://github.com/projectY/projectY/

  3. thêm tác giả gốc và tất cả các tác giả của các yêu cầu kéo (đã được hợp nhất và vẫn mở) làm quản trị viên tổ chức
  4. tạo lại tất cả các yêu cầu kéo (mở) từ repo ban đầu trong ngã ba mới
  5. làm tương tự với các vấn đề (mở)
  6. thông báo cho tất cả các quản trị viên của repo mới
  7. tạo một yêu cầu kéo cuối cùng cho repo cũ, thêm thông báo và liên kết "bị bỏ rơi" / "đã lưu trữ" vào repo mới trên đầu trang của README

Vấn đề chính tôi thấy với cách tiếp cận này, là một số người đóng góp "xấu" có thể có quyền truy cập của quản trị viên, nhưng như nhà truyền giáo phần mềm miễn phí, ông Pieter Hintjens giải thích (ví dụ như trong bài nói chuyện này) , các cam kết xấu có thể được hoàn nguyên và không đưa ra chủ đề nào một dự án còn sống và có thể giúp người đi làm xấu trở thành một người tốt, theo thời gian.
hoijui
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.