Làm cách nào để đối phó với một người lập trình khó khăn khi tham gia một dự án nguồn mở?


65

Tôi có một tập lệnh mã nguồn mở cho một trang web cụ thể (Tôi đang cố gắng không gọi bất cứ thứ gì theo tên ở đây) mà tôi và một vài nhà phát triển khác gần đây đã chuyển sang GitHub. Chúng tôi đã nhận được một số nhà phát triển mới kể từ khi chúng tôi chuyển sang hệ thống mới, đặc biệt là một nhà phát triển rất tích cực. Tuy nhiên, hoạt động này đã bắt đầu thay đổi rất nhiều dự án.

Trước hết, anh ấy đã xóa hệ thống phiên bản của chúng tôi (không giống như Git, nhưng như thế - chúng tôi gọi đó là phiên bản v4.1.16) và nói rằng sẽ tốt hơn nếu chỉ cần đẩy mã lên trang web khi chúng tôi nghĩ rằng nó đã sẵn sàng. Bây giờ không có nơi tập trung để đặt ghi chú phát hành, điều này đã gây phiền nhiễu.

Điều khiến tôi chuẩn bị sẵn sàng để đóng gói hành lý của mình là kịch bản đẩy. Một nhà phát triển khác trong dự án đã viết một kịch bản đẩy dựa trên Python đơn giản. Vì chúng tôi giữ nhiều phiên bản của tập lệnh trực tuyến ở nhiều nơi khác nhau, tôi bắt đầu mã hóa một chương trình Java lớn hơn với giao diện đồ họa sẽ thay thế tập lệnh Python. Tôi đã đến IRC để thông báo cho mọi người về nó và tôi đã nhận được phản hồi rất khó chịu từ lập trình viên nói rằng kịch bản dựa trên Python cũ có thể làm mọi thứ tôi có thể làm và nhẹ hơn rất nhiều (anh ấy cũng nhận xét về sự thật mà anh ấy nghĩ Python tốt hơn Java và vân vân). Tôi đã xem qua mã cho tập lệnh đẩy cũ và thấy rằng không có tính năng nào ông nói tồn tại ở đó.

Vì vậy, bây giờ tôi muốn biết phải làm gì. Tôi đã dành rất nhiều thời gian cho dự án này, vì vậy tôi không muốn thức dậy và rời đi, nhưng tôi cảm thấy khó khăn khi làm việc với nhà phát triển mới này. Mặt khác, anh ấy hiện là người giao dịch số 1 trong dự án, với nhiều cam kết hơn cả nhà phát triển chính. Tôi không thực sự chắc chắn phải làm gì về điều này. Có ai khác gặp vấn đề này? Nếu đúng thế thì bạn đã làm gì?

CẬP NHẬT 1 : Tôi đã vô hiệu hóa quyền truy cập cam kết của mọi người và tôi đang yêu cầu mọi người thực hiện các yêu cầu kéo. Tôi cũng đề xuất một số biện pháp để khắc phục các vấn đề khác. Mọi người khác đã không thể hiện bất kỳ sự hỗ trợ nào cho nó. Nhà phát triển rắc rối đã nói đơn giản rằng những người không theo dõi "hành động cam kết" chặt chẽ có thể nghĩ rằng dự án bị vô tổ chức khi nó thực sự không. Tôi rõ ràng không đồng ý với điều này, vì vậy tôi nghiêm túc suy nghĩ về việc từ chức khỏi dự án.

CẬP NHẬT 2 : Nhà phát triển chính bắt đầu ca ngợi về việc một trong những cam kết của tôi được cho là đã xóa ba dòng mới trong mã (cam kết hoàn nguyên xuất hiện ngay sau khi tôi đăng thảo luận và thậm chí không tham khảo "cam kết" của mình), và sau đó hai người họ bắt đầu thảo luận về việc có nên thu hồi quyền truy cập cam kết của tôi không. Vì vậy, tôi đã làm điều hợp lý và rời khỏi dự án. Cảm ơn sự giúp đỡ của bạn với điều này tất cả mọi người!


46
Làm thế nào một người có thể tự thay đổi hệ thống phiên bản? Chắc chắn anh ta phải có sự ủng hộ phổ biến, ít nhất là trong số những người. Và, đánh giá bằng một bình luận khác, đã có một sự thay đổi giấy phép để giới hạn tất cả - Tại sao các bạn không có tiếng nói hơn khi nền tảng của dự án của bạn đột nhiên bị lung lay / thay thế?
Deer Hunter

32
Bạn đang thiếu điểm của câu hỏi. Làm thế nào một người mới tham gia dự án của bạn và dường như mất toàn bộ? Nó có thể là nguồn mở nhưng nó ngụ ý rằng có một nhà lãnh đạo hoặc một nhóm các nhà lãnh đạo và có lẽ rằng / những nhà lãnh đạo đó sẽ là những người duy nhất có khả năng thay đổi các phần quan trọng như vậy về cách thức vận hành dự án.
alroc

35
Đây là dự án của bạn trên github, đúng không? Có một lý do bạn không thể loại bỏ quyền truy cập của anh ấy vào dự án? Hoặc anh ấy tự làm cái nĩa của riêng mình mà bạn có thể lấy từ nếu bạn thích những thay đổi? Nếu ai đó tự mình lấy nó để thay đổi cách mã được phiên bản trong một dự án của tôi, họ sẽ biến mất ngay lập tức.
GrandmasterB

6
Bạn làm nghề gì? Bạn đăng bài trên TheD DailyWTF và chia sẻ liên kết với mọi người. Bạn sẽ xấu hổ cho anh ta trình.
Rath

24
Thành thật mà nói, và bất kể các vấn đề khác đang bị đe dọa ở đây, việc thay thế một tập lệnh Python bằng một chương trình Java đồ họa để đẩy phần mềm lên một trang web trông giống như sự áp đảo điên rồ đối với tôi.
sam hocevar

Câu trả lời:


55
  1. Bạn có thể bỏ. Không phải là điều mang tính xây dựng nhất, nhưng đôi khi đó là lựa chọn duy nhất. Nếu bạn làm thế, đừng ngồi một chỗ và rên rỉ về cách bạn phải từ bỏ nó, hãy lấy năng lượng đó và đưa thẳng vào một thứ khác - 'tiếp tục' nói cách khác.

  2. Bạn có thể ngã ba nó. Không có lý do tại sao bạn phải làm việc với bất cứ ai. Ngã ba, cải thiện mã và để cho những người khác tiếp tục có một chút lễ hội bản ngã của riêng họ. Dự án mới của bạn sẽ đơn giản cạnh tranh với cái cũ và tùy thuộc vào bạn cho dù bạn thành công với nó hay dự án cũ đánh bại bạn về mặt người dùng và tính năng.

  3. Bạn có thể tham gia với phần còn lại của nhóm phát triển trong dự án để nói lên mối quan tâm của bạn. Đừng biến nó thành cá nhân, nhưng hãy nhận ra rằng bạn không hài lòng với mã nguồn, hoặc thiếu các quy trình chất lượng đã được thiết lập hoặc không hài lòng rằng các quyết định mới chỉ bị đẩy ra mà không có sự đồng ý từ mọi người. Bạn sẽ được thông báo rằng không có gì sai đủ để thay đổi, hoặc bạn sẽ khiến một vài người khác đồng ý với bạn rằng nhóm cần sửa chữa mọi thứ. Điều đó có thể kết thúc với việc anh chàng quậy phá mất quyền truy cập cam kết của mình. Có thể tất cả bạn sẽ đồng ý rằng một số thay đổi không phải là cải tiến và dự án cần phải được hoàn nguyên. (Tùy chọn thứ hai này là kết quả rất có thể, trừ khi nó biến thành một cuộc tranh luận lớn về các ý kiến ​​cố thủ.)

Có thể khó khăn khi có ai đó đi cùng và thay đổi thói quen an toàn và thoải mái mà bạn đã quen, nhưng có thể nói rằng có ai đó đi cùng và rũ bỏ những thói quen cũ, ấm cúng là những điều tốt đẹp trong chính họ.


2
Tôi muốn đề xuất một ngã ba ();
ott--

1
Tại sao lại để lại như là giải pháp số 1? Nếu dự án thực sự thú vị, đó có nên là lựa chọn cuối cùng không?
Deer Hunter

2
@DeerHunter: Tôi không đọc thứ tự các khả năng theo thứ tự ưu tiên, nhưng thật hữu ích khi có 1,2 được liệt kê đầu tiên vì những khả năng này có thể thông báo cho cuộc thảo luận về 3.
hardmath

36
tùy chọn được liệt kê theo thứ tự dễ nhất để loại ra.
gbjbaanb

Hoán đổi số 3 với số 1, bạn phải đẩy lùi vì một con sói đơn độc không quan tâm đến bất cứ điều gì khác có thể phá hủy một dự án tốt.
Jonathan Neufeld

39

Bạn đã làm cho nó một chút không rõ ràng chính xác vai trò của bạn ở đây là gì. Câu trả lời phụ thuộc vào cách bạn phù hợp.

Nếu bạn đang dẫn dắt dự án và kiểm soát kho git

Lấy lại quyền kiểm soát. Nếu anh chàng này thực hiện các cam kết mà bạn không thích mà không hỏi ý kiến ​​bạn, hãy xóa quyền truy cập cam kết trực tiếp của anh ta. Anh ta có thể rẽ nhánh dự án và thực hiện các yêu cầu kéo để hợp nhất các cam kết của mình. Đó là cách nguồn mở nên hoạt động cho đến khi người dùng tạo dựng niềm tin. Bạn không cần và không nên cung cấp quyền truy cập đầy đủ ngay lập tức.

Nếu ai đó điều khiển repo

Thể hiện mối quan tâm của bạn với người thực hiện và khuyến khích một quy trình kỷ luật hơn để lập kế hoạch và phê duyệt các thay đổi. Nếu ban lãnh đạo không tuân theo quy trình, thì bạn có thể chọn chấp nhận hiện trạng và tiếp tục đóng góp, bạn có thể rẽ nhánh dự án và làm việc trên phiên bản của riêng bạn (mang theo bất kỳ ai đồng ý với bạn) hoặc bạn có thể chọn rời khỏi và làm việc trên những thứ khác. Trong mọi trường hợp, bạn không cần phải tiếp tục giải quyết việc này.


23

Xin vui lòng tha thứ cho sự thẳng thừng của tôi, nhưng bài viết của bạn đọc như một lời ca ngợi.

Bạn nói rằng đó là người khác muốn thay đổi không suy nghĩ, nhưng sau đó bạn mâu thuẫn với chính mình khi nói về chương trình Java sáng bóng mới này của bạn.

Nghỉ ngơi một lát; đó không phải là con đường một chiều, vui lòng cố gắng tìm sự thỏa hiệp (nếu bạn muốn tiếp tục thực hiện dự án - forking là quyết định dễ dàng nhất nhưng nó sẽ không dẫn bạn đến bất cứ nơi nào hữu ích, mặc dù nó có thể đánh bại cái tôi của bạn).

Ngoài ra, hãy suy nghĩ kỹ về sự phân công lao động trong dự án - chiến tranh sân cỏ là không thể tránh khỏi nếu bạn không có ranh giới trong sạch cho bạn biết ai có năng lực trong việc gì . Vâng, đôi khi bạn phải tin tưởng vào sự phán xét của người khác.


4
@ Nathan2055 - Đơn giản và làm việc tốt hơn, trong cuốn sách của tôi (có lẽ đó chỉ là tôi). Dù sao, có vẻ như dự án là adrift mà không có nhiều hướng dẫn.
Deer Hunter

1
Tôi đồng ý với phần adrift. Một trong những điều tôi quên đề cập đến là cùng một nhà phát triển đã phát hành lại dự án một cách ngẫu nhiên mà không nói cho ai biết.
Nathan2055

24
Chính xác, làm thế nào mà một nhà phát triển mới đơn phương thay đổi giấy phép trên một bộ mã hiện có mà anh ta không có quyền kiểm soát bản quyền duy nhất? Làm thế nào mà anh ta có được quyền truy cập / quyền hạn như vậy và tại sao nó không bị lấy đi?
KutuluMike

7
Toàn bộ tình huống này không thêm. Không ai có thể đi và đơn phương thay đổi giấy phép cho một dự án hệ điều hành. Vì bạn chưa đồng ý và (tôi cho rằng) bạn đã đóng góp, thay đổi của anh ấy có nghĩa là ngồi xổm.
Norcross

9
@ Nathan2055 Thay đổi giấy phép của dự án mà không được phép có lẽ là căn cứ để sa thải ngay lập tức, ngay cả trong các dự án nguồn mở. Chỉ vì nó là nguồn mở không có nghĩa là một số anh chàng ngẫu nhiên có thể bước vào và nắm quyền kiểm soát. Cho dù kỹ năng lập trình của anh ấy tuyệt vời đến thế nào, nếu anh ấy không thể làm việc trong một nhóm bạn không muốn anh ấy ở đó và bạn cần nói chuyện với anh ấy và / hoặc đuổi anh ấy ra. Trừ khi bạn không nói cho chúng tôi tất cả mọi thứ ..
Thomas

10

Nó đã được đề cập trong một số câu trả lời rằng phân công lao động là một cách để giảm xung đột. Dưới đây là một số ví dụ cụ thể:

  1. Cân bằng năng suất so với sự ổn định. Để mượn một sự tương tự từ các trò chơi chiến lược, một đội phải bao gồm sự pha trộn giữa Boom, Rùa và Rush , và các đồng đội phải được chuẩn bị để thay đổi vai trò để ứng phó với tình huống.
    • Khi một người đang trong cơn sốt năng suất, những người khác có thể làm việc:
    • Các tính năng khác
    • Sửa lỗi
    • Thông số kỹ thuật (quản lý các yêu cầu tính năng mới và xác minh rằng phần mềm đáp ứng các tiêu chí đã thỏa thuận)
    • Đảm bảo chất lượng
      • Kiểm tra thủ công (thăm dò)
      • Kiểm tra tự động
    • Tài liệu
    • Tái cấu trúc và dọn dẹp mã
    • Tiến hành nghiên cứu người dùng để thu thập ý tưởng để cải tiến
    • Vân vân.
  2. Một dự án có thể được mô đun hóa (như trong kiến ​​trúc phần mềm), hoặc thậm chí được ngăn cách (như trong quản lý dự án) để mỗi mô-đun có thể được làm việc độc lập.
    • Nói chung, hầu hết các phần mềm chứa cả front-end và back-end nên được mô đun hóa, bởi vì chúng có tốc độ phát triển khác nhau.
    • Phần mềm giàu UX có thể khó mô đun hóa do sử dụng nhiều định tuyến sự kiện mô-đun chéo.
    • Người bảo trì dự án có thể muốn giữ cho dự án đơn giản bằng cách tránh mô đun hóa.
  3. Chi nhánh tính năng . Mỗi nhà phát triển có thể phân nhánh dự án, làm việc trên tính năng thú cưng yêu thích của mình và yêu cầu hợp nhất khi quá trình thực hiện hoàn tất. Nhà phát triển chính có thể có tiếng nói cuối cùng trong việc có chấp nhận hợp nhất hay không.

Ngoài khía cạnh tránh xung đột, rõ ràng dự án có thể không đủ quản trị .

Tại sao quản trị quan trọng? Hãy tưởng tượng một ngày, một đồng đội cũ lấy một phần mềm và kiện nhóm vi phạm. Hoặc nhóm bị kiện bởi troll bằng sáng chế. Hoặc không ai biết ai đã quyết định gửi thông báo DMCA đến trang web lưu trữ dự án và yêu cầu xóa mã nguồn của dự án.

Tối thiểu:

  • Giấy phép được sử dụng bởi tất cả các mã nguồn đóng góp
  • (Các) giấy phép theo đó mã nguồn của dự án có thể được xuất bản
    • Trong trường hợp giấy phép công cộng mới được tìm kiếm, làm thế nào để có được sự đồng ý từ mọi người đóng góp
  • Ai có thể có quyền truy cập quản trị vào dự án
  • Ai sẽ được chỉ định trả lời các yêu cầu pháp lý (chẳng hạn như thông báo DMCA hoặc troll bằng sáng chế)
  • Ai sẽ quản lý tài chính cho dự án (thanh toán chi phí máy chủ và ghi sổ doanh thu quảng cáo hoặc quyên góp)
  • Ai sẽ có quyền biểu quyết để bao gồm thành viên mới và trục xuất thành viên.
  • Vân vân.

Hầu hết các trang web dự án nguồn mở có thể cung cấp các biểu đồ quản trị dự án làm sẵn.


1
+1 cho quản trị. Sớm hay muộn tất cả các dự án nguồn mở đều cần một số quy tắc bằng văn bản cũng như một số mã, cho dù đó là quản trị toàn diện cho các dự án lớn hay chỉ là một quy tắc ứng xử đơn giản (như wiki.gnome.org/CodeOfConduct ) cho bất kỳ diễn đàn, danh sách gửi thư nào , cơ sở dữ liệu lỗi hoặc SCCS tất cả các bạn chia sẻ.
calum_b

9

Tôi đã thấy vấn đề trước đây. Nhưng sau vài năm bạn thực sự cảm thấy mệt mỏi với dự án, vì vậy giải pháp của tôi là rời khỏi dự án . Nó có thể không làm việc cho bạn, nhưng vấn đề cơ bản là những người khác nhau nghĩ theo những cách khác nhau. Các tính năng mà bạn nghĩ là rất quan trọng hoàn toàn không quan trọng đối với người khác.

Kế hoạch tốt sẽ là phân chia nhiệm vụ của những người khác nhau. Nếu bạn có thể đồng ý với những người mà một phần của dự án thuộc trách nhiệm của mỗi người, thì chỉ có một người đang đưa ra quyết định về một phần nào đó của dự án. Nhưng làm việc nhóm luôn khó khăn. Bạn vẫn sẽ không bao giờ thích những quyết định của các lập trình viên khác. Giải pháp tốt nhất là không bao giờ nhìn vào những gì các lập trình viên khác quyết định. Chỉ cần tin tưởng họ làm điều đúng là đủ.

Mục tiêu chung sẽ tập trung nỗ lực của bạn vào những thứ quan trọng. Mọi người làm việc theo cùng một hướng rất khó để có được, và xung đột dù sao cũng sẽ xảy ra. Quyết định mục tiêu chung đòi hỏi phải biết tình trạng hiện tại của dự án là gì, và sau đó quyết định nơi cần đến sau một thời gian.

Đây là ví dụ về những thứ cần tránh: Ví dụ, số lượng lớn lập trình viên c ++ nghĩ rằng mã không sử dụng thư viện STL bị hỏng. Các lập trình viên khác nghĩ rằng mọi sự phụ thuộc vào các thư viện bên ngoài đều bị phá vỡ, bao gồm cả STL. Những xung đột như vậy không thể được giải quyết đúng đắn - cả hai tình huống không thể được giải quyết đầy đủ một cách đồng thời - và những người có vấn đề nhất sẽ thúc đẩy ý kiến ​​của họ bất kể họ sẽ gặp phải sự phản đối nào.


Một điểm tốt về phân công lao động.
Deer Hunter

3
Không bao giờ nhìn vào những gì lập trình viên khác quyết định, chỉ cần tin tưởng họ? Nghe có vẻ nguy hiểm với tôi. Còn kiểm soát chất lượng thì sao?
Stephan

6

Bốn lựa chọn, tôi nghĩ.

  1. Đá anh ta ra. Bạn (được cho là) ​​vẫn là anh chàng chính trong dự án này; thu hồi đặc quyền đẩy của mình và gọi nó là một ngày. Kết quả rất có thể là anh ta đã hủy bỏ dự án, chia rẽ cộng đồng của nó, và sau đó một cuộc chiến nổ ra, và khi bụi lắng xuống, một trong những ngã ba sẽ là một trong những ngã ba phổ biến.
  2. Ngã ba nó và tiếp tục ở nơi khác. Ít tích cực hơn 1., nhưng hậu quả là như nhau. Bạn sẽ phải tích cực trong cộng đồng mặc dù để kéo mọi người về phía bạn.
  3. Cứ để đó là: hãy để anh ấy làm những gì anh ấy đang làm, bình tĩnh và hy vọng điều tốt nhất.
  4. Thảo luận với cộng đồng, thỏa hiệp theo yêu cầu và giải quyết tình huống.

Cá nhân, tôi thích tùy chọn 4.


6

Google đã có một vài cuộc thảo luận về công nghệ về điều này vài năm trước. Xem họ:1 ,2 . Tóm lại:

  1. Hiểu : Hiểu được động lực của cộng đồng để làm việc trong dự án của bạn so với tất cả các chi phí cơ hội khác và bảo tồn những lý do đó.
  2. Fortify : Xây dựng một cộng đồng lành mạnh với các chuẩn mực xã hội về sự lịch sự, tôn trọng, tin tưởng và khiêm tốn.
  3. Xác định : Tìm kiếm dấu hiệu của những người độc hại (quá nhiều để liệt kê, nhưng nếu bạn đang hỏi câu hỏi này thì có lẽ bạn đã biết nhiều người trong số họ).
  4. Khử trùng : Hãy bình tĩnh và giữ vững lập trường của bạn, vẫn không hợp lý với những lời lăng mạ, tráo trở, thách thức, thiếu tôn trọng, v.v., và kiên trì củng cố các quy tắc cộng đồng của bạn.

Một phác thảo bằng văn bản toàn diện cũng có sẵn nếu bạn thích đọc thay vì xem.


3
bạn có muốn mở rộng một chút về những gì mỗi tài nguyên này có và tại sao bạn lại đề xuất những tài nguyên này khi trả lời câu hỏi không? "Câu trả lời chỉ liên kết" không được chào đón tại Stack Exchange
gnat

1
Đã thêm tóm tắt, thế nào?
Kurtosis

5

Bạn không thể bỏ mà không nỗ lực để bày tỏ mối quan tâm và khó khăn của bạn. Tôi biết nó có thể khó khăn. Nếu thực tế nếu bạn và các thành viên trong nhóm của bạn đủ trẻ để không gặp phải nhiều vấn đề xã hội xảy ra trong bất kỳ nhóm phát triển nào, thì điều đó có thể thực sự khó khăn.

Có nói rằng, tôi tin tưởng mạnh mẽ bạn nên bày tỏ mối quan tâm của bạn. Bạn có thể viết chúng trong email và hiển thị nó cho những người bạn đáng tin cậy của bạn, những người không thuộc nhóm và không có hoặc ít quan tâm đến những gì bạn làm. Trong trường hợp này, bạn có thể nhận được phản hồi tốt để từ ngữ email của bạn không quá khắc nghiệt. Bám sát sự thật mặc dù. Đừng buộc tội hay đổ lỗi. Chỉ cần sự thật là khó có thể làm điều gì đó cho bạn vì 'blah' bị thiếu. Tại sao 'blah' bị thiếu nên rõ ràng đối với mọi thành viên trong nhóm, tức là "lập trình viên mới" đã xóa hoặc không hoàn thành điều gì đó.

Một lần nữa, gửi email này là khó khăn nhưng bản thân nó là một kinh nghiệm tuyệt vời có thể rất hữu ích cho bạn trong tương lai. Bài học tuyệt vời để học hỏi.

Tái bút: Tôi không có ý nói quá phụ huynh. Tuy nhiên, đó thực sự là điều tôi sẽ nói với bất cứ ai kể cả những đứa trẻ của tôi.


7
"Bạn không thể bỏ" ... Có, bạn có thể . Bạn không nên lựa chọn nhẹ nhàng vì điều đó có nghĩa là bạn sẽ đốt cháy mọi cây cầu với mọi người khác trong đội nếu bạn làm vậy, nhưng nếu tình huống đủ tồi tệ (đến mức gây ra cảm xúc đau khổ), chỉ cần đi bộ luôn là một lựa chọn .
Shadur
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.