ฉันจะจัดการกับโปรแกรมเมอร์ยาก ๆ ที่เข้าร่วมโครงการโอเพ่นซอร์สได้อย่างไร

ฉันมีสคริปต์โอเพนซอร์ซสำหรับเว็บไซต์หนึ่ง ๆ (ฉันพยายามไม่เรียกชื่ออะไรเลยที่นี่) ซึ่งฉันและนักพัฒนาซอฟต์แวร์รายอื่นเพิ่งย้ายมาที่ GitHub เราได้นักพัฒนาใหม่หลายคนตั้งแต่เราย้ายไปที่ระบบใหม่รวมถึงหนึ่งที่ใช้งานมากโดยเฉพาะ อย่างไรก็ตามสิ่งนี้ที่ใช้งานอยู่ได้เริ่มเปลี่ยนโครงการเป็นจำนวนมาก

ก่อนอื่นเขาลบระบบการกำหนดเวอร์ชันของเรา (ไม่เหมือน Git แต่เป็นแบบนั้น - เราเรียกมันว่ารุ่นv4.1.16) และบอกว่ามันจะเป็นการดีกว่าที่จะส่งรหัสไปยังเว็บไซต์เมื่อเราคิดว่ามันพร้อม ขณะนี้ไม่มีสถานที่รวมศูนย์สำหรับวางบันทึกย่อประจำรุ่นซึ่งทำให้เกิดความรำคาญ

สิ่งที่ทำให้ฉันพร้อมที่จะแพ็คกระเป๋าของฉันและไปคือสคริปต์การผลักดัน ผู้พัฒนารายอื่นในโครงการเขียนสคริปต์พุชแบบ Python เนื่องจากเราเก็บสคริปต์หลายเวอร์ชันออนไลน์ไว้ในที่ต่าง ๆ ฉันจึงเริ่มเขียนโปรแกรม Java ที่ใหญ่ขึ้นด้วยส่วนต่อประสานกราฟิกที่จะแทนที่สคริปต์ Python ฉันไปที่ IRC เพื่อแจ้งให้ทุกคนทราบเกี่ยวกับเรื่องนี้และฉันได้รับคำตอบที่น่ารำคาญจากโปรแกรมเมอร์ว่าสคริปต์ Python แบบเก่าสามารถทำทุกอย่างที่ฉันสามารถทำได้และมีน้ำหนักเบากว่ามาก (เขายังแสดงความคิดเห็นเกี่ยวกับข้อเท็จจริงที่ Python ดีกว่า Java และอื่น ๆ ) ฉันตรวจดูรหัสสำหรับสคริปต์การพุชเก่าและเห็นว่าไม่มีฟีเจอร์ใด ๆ ที่เขากล่าวว่ามีอยู่

ตอนนี้ฉันอยากรู้ว่าต้องทำอะไร ฉันใช้เวลาส่วนใหญ่ในโครงการนี้ดังนั้นฉันจึงไม่ต้องการลุกขึ้นและจากไป แต่ฉันพบว่ามันยากที่จะทำงานร่วมกับนักพัฒนาใหม่นี้ ในทางกลับกันตอนนี้เขาเป็นผู้ร่วมเดินทางอันดับ 1 ในโครงการโดยมีความมุ่งมั่นมากกว่าผู้พัฒนากลุ่มเป้าหมาย ฉันไม่แน่ใจจริงๆว่าจะทำอย่างไรกับเรื่องนี้ มีใครประสบปัญหานี้อีกหรือไม่ ถ้าเป็นเช่นนั้นคุณทำอะไร

อัปเดต 1 : ฉันได้ปิดการใช้งานการเข้าถึงของทุกคนและฉันขอให้ผู้คนทำตามคำขอดึง ฉันยังเสนอมาตรการหลายอย่างเพื่อแก้ไขปัญหาอื่น ๆ คนอื่นไม่ได้แสดงการสนับสนุนใด ๆ นักพัฒนาที่มีปัญหาพูดง่าย ๆ ว่าคนที่ไม่ปฏิบัติตาม "กระทำการกระทำ" อย่างใกล้ชิดสามารถคิดได้ว่าโครงการจะสับสนเมื่อมันไม่จริง เห็นได้ชัดว่าฉันไม่เห็นด้วยกับสิ่งนี้ดังนั้นฉันจึงใคร่ครวญถึงการลาออกจากโครงการอย่างจริงจัง

อัปเดต 2 : ผู้พัฒนานำเริ่มคุยโวเกี่ยวกับความจริงที่ว่าหนึ่งในคอมมิทของฉันควรลบบรรทัดใหม่สามบรรทัดในโค้ด (การย้อนกลับคอมมิชชันปรากฏขึ้นหลังจากที่ฉันโพสต์การสนทนา พวกเขาสองคนเริ่มถกเถียงกันว่าจะเพิกถอนสิทธิ์การเข้าถึงของฉันหรือไม่ ดังนั้นฉันได้ทำสิ่งที่เป็นตรรกะและออกจากโครงการ ขอบคุณสำหรับความช่วยเหลือของคุณกับทุกคนนี้!

1. คุณสามารถออกจาก ไม่ใช่สิ่งที่สร้างสรรค์ที่สุดที่ต้องทำ แต่บางครั้งก็เป็นเพียงตัวเลือกเดียว หากคุณเป็นเช่นนั้นอย่านั่งเฉยและคร่ำครวญว่าคุณจะยอมแพ้ใช้พลังงานนั้นและวางมันลงไปในสิ่งอื่น - 'ก้าวต่อไป' ในคำอื่น ๆ

2. คุณสามารถแยกมันได้ ไม่มีเหตุผลใดที่คุณต้องทำงานกับทุกคน แยกปรับปรุงรหัสและปล่อยให้คนอื่น ๆ ยังคงมีอัตตาตัวเองเล็กน้อย โครงการใหม่ของคุณจะแข่งขันกับโครงการเก่าและขึ้นอยู่กับคุณไม่ว่าคุณจะประสบความสำเร็จหรือโครงการเก่าจะชนะคุณในแง่ของผู้ใช้และคุณสมบัติ

3. คุณสามารถมีส่วนร่วมกับทีมพัฒนาส่วนที่เหลือในโครงการเพื่อแสดงความกังวลของคุณ อย่าทำให้เป็นเรื่องส่วนตัว แต่ทำให้คุณไม่มีความสุขกับการเปลี่ยนแปลงของโค้ดหรือการขาดกระบวนการคุณภาพที่กำหนดไว้หรือไม่พอใจว่าการตัดสินใจครั้งใหม่จะถูกผลักออกไปโดยปราศจากข้อตกลงจากทุกคน คุณจะได้รับการบอกว่าไม่มีอะไรผิดปกติพอที่จะเปลี่ยนแปลงหรือคุณจะได้รับคนอื่นเห็นด้วยกับคุณว่าทีมต้องแก้ไขสิ่งต่าง ๆ นั่นอาจจบลงด้วยคนที่ก่อกวนทำให้สูญเสียการเข้าถึง บางทีคุณอาจเห็นด้วยว่าการเปลี่ยนแปลงบางอย่างไม่ใช่การปรับปรุงและโครงการจะต้องเปลี่ยนกลับ (ตัวเลือกหลังนี้เป็นผลลัพธ์ที่น่าจะเป็นไปได้มากที่สุดเว้นแต่ว่ามันจะกลายเป็นข้อโต้แย้งขนาดใหญ่ของความคิดเห็นที่ยึดที่มั่น)

อาจเป็นเรื่องยากเมื่อใครบางคนเข้ามาและเปลี่ยนกิจวัตรที่ปลอดภัยและสะดวกสบายที่คุณคุ้นเคย แต่อาจกล่าวได้ว่าการมีใครบางคนเข้ามาและสั่นคลอนแนวทางปฏิบัติเก่า ๆ ที่อบอุ่นเป็นสิ่งที่ดีในตัวเอง

คุณทำให้มันชัดเจนเล็กน้อยว่าบทบาทของคุณคืออะไรที่นี่ คำตอบขึ้นอยู่กับว่าคุณเหมาะสมกับอะไร

หากคุณเป็นผู้นำโครงการและควบคุมที่เก็บ git

นำการควบคุมกลับมา หากชายคนนี้กำลังทำสิ่งที่คุณไม่ชอบโดยไม่ปรึกษาคุณให้ลบการกระทำโดยตรงของเขา เขาสามารถแยกโครงการและทำคำขอดึงเพื่อรวมการกระทำของเขา นั่นคือวิธีที่โอเพนซอร์สควรทำงานจนกว่าผู้ใช้จะสร้างความไว้วางใจ คุณไม่จำเป็นต้องและไม่ควรให้สิทธิ์เข้าถึงแบบเต็มทันที

ถ้ามีคนอื่นควบคุม repo

แสดงความกังวลของคุณต่อบุคคลที่ทำและสนับสนุนให้มีกระบวนการทางวินัยมากขึ้นในการวางแผนและอนุมัติการเปลี่ยนแปลง หากความเป็นผู้นำไม่ได้รับการตอบสนองต่อกระบวนการคุณสามารถเลือกที่จะยอมรับสภาพที่เป็นอยู่และมีส่วนร่วมได้คุณสามารถแยกโครงการและทำงานในเวอร์ชันของคุณเอง และทำงานกับสิ่งอื่น ๆ ไม่ว่าในกรณีใดคุณไม่จำเป็นต้องจัดการกับสิ่งนี้ต่อไป

โปรดยกโทษให้ฉันทื่อ แต่โพสต์ของคุณอ่านเหมือนคุยโว

คุณบอกว่ามันเป็นอีกคนที่ต้องการการเปลี่ยนแปลงที่ไร้เหตุผล แต่เมื่อคุณพูดถึงโปรแกรม Java อันใหม่นี้ของคุณ

หยุดพัก; ไม่ใช่ถนนเดินรถทางเดียวโปรดลองหาการประนีประนอม (หากคุณต้องการทำงานในโครงการต่อไป - การตีคือการตัดสินใจที่ง่ายที่สุด แต่มันจะไม่นำคุณไปสู่ทุกที่ที่มีประโยชน์

โปรดคิดอย่างละเอียดเกี่ยวกับการแบ่งงานในโครงการ - สงครามสนามหญ้าอย่างหลีกเลี่ยงไม่ได้ถ้าคุณไม่ได้มีขอบเขตสะอาดบอกคุณผู้ที่มีอำนาจในสิ่งที่ ใช่คุณต้องเชื่อใจการตัดสินของคนอื่นในบางครั้ง

มีการกล่าวถึงแล้วในคำตอบหลายข้อว่าการแบ่งงานเป็นวิธีหนึ่งในการลดความขัดแย้ง นี่คือตัวอย่างที่เป็นรูปธรรม:

1. ยอดคงเหลือผลผลิตเทียบกับความมั่นคง ในการขอยืมอุปมาจากเกมวางแผนทีมต้องประกอบด้วยBoom, Turtle and Rushและเพื่อนร่วมทีมต้องพร้อมที่จะเปลี่ยนบทบาทเพื่อตอบสนองต่อสถานการณ์
   • เมื่อสิ่งหนึ่งอยู่ในความนิยมที่เพิ่มขึ้นผู้อื่นสามารถทำงานต่อได้:
   • คุณสมบัติอื่น ๆ
   • แก้ไขข้อผิดพลาด
   • ข้อมูลจำเพาะ (การจัดการคำขอคุณลักษณะใหม่และตรวจสอบว่าซอฟต์แวร์ตรงตามเกณฑ์ที่ตกลงร่วมกัน)
   • รับประกันคุณภาพ
     • การทดสอบด้วยตนเอง (สำรวจ)
     • การทดสอบอัตโนมัติ
   • เอกสาร
   • การรีแฟคเตอร์และการล้างโค้ด
   • ทำการศึกษาผู้ใช้เพื่อรวบรวมแนวคิดสำหรับการปรับปรุง
   • เป็นต้น
2. โครงการสามารถทำให้เป็นโมดูล (เช่นในสถาปัตยกรรมซอฟต์แวร์) หรือแม้กระทั่งแยกส่วน (ในการจัดการโครงการ) เพื่อให้แต่ละโมดูลสามารถทำงานได้อย่างอิสระ
   • โดยทั่วไปซอฟต์แวร์ส่วนใหญ่ที่มีทั้ง front-end และ back-end ควรเป็นโมดูลเพราะพวกเขามีความเร็วในการพัฒนาที่แตกต่างกัน
   • ซอฟต์แวร์ UX-rich อาจยากที่จะทำให้เป็นโมดูลเนื่องจากการใช้งานหนักของการกำหนดเส้นทางข้ามโมดูล
   • ผู้ดูแลโครงการอาจต้องการทำให้โครงการง่ายขึ้นโดยหลีกเลี่ยงการทำให้เป็นโมดูล
3. สาขาคุณสมบัติ ผู้พัฒนาแต่ละคนสามารถแยกโครงการทำงานบนคุณสมบัติสัตว์เลี้ยงที่ตนชอบและขอรวมเมื่อการใช้งานเสร็จสมบูรณ์ ผู้พัฒนานำสามารถพูดสุดท้ายว่าจะยอมรับการผสานหรือไม่

นอกเหนือจากด้านความขัดแย้งการหลีกเลี่ยงที่จะเห็นได้ชัดว่าโครงการที่อาจมีไม่เพียงพอการกำกับดูแล

ทำไมการกำกับดูแลจึงมีความสำคัญ ลองนึกภาพสักวันหนึ่งอดีตเพื่อนร่วมทีมนำซอฟต์แวร์มาหนึ่งชิ้นแล้วฟ้องทีมเพื่อการละเมิด หรือทีมฟ้องร้องโดยโทรลล์สิทธิบัตร หรือไม่มีใครรู้ว่าใครเป็นคนตัดสินใจที่จะส่งประกาศ DMCA ไปยังไซต์ที่โฮสต์โครงการและเรียกร้องให้ลบซอร์สโค้ดของโครงการ

อย่างน้อย:

• สิทธิ์ใช้งานที่จะใช้โดยซอร์สโค้ดที่สนับสนุนทั้งหมด
• ใบอนุญาตที่สามารถเผยแพร่ซอร์สโค้ดของโครงการได้
  • ในกรณีที่มีการขอใบอนุญาตสาธารณะใหม่วิธีการขอความยินยอมจากผู้มีส่วนร่วมทุกคน
• ใครสามารถมีสิทธิ์การเข้าถึงระดับผู้ดูแลระบบสำหรับโครงการ
• ผู้ที่จะได้รับมอบหมายให้ตอบคำขอตามกฎหมาย (เช่นประกาศ DMCA หรือโทรลล์สิทธิบัตร)
• ใครจะเป็นผู้บริหารการเงินสำหรับโครงการ (จ่ายค่าเซิร์ฟเวอร์และทำบัญชีรายได้โฆษณาหรือบริจาค)
• ใครบ้างที่จะมีสิทธิออกเสียงในการรวมสมาชิกใหม่และสมาชิกขับไล่
• เป็นต้น

ไซต์โครงการโอเพ่นซอร์สส่วนใหญ่สามารถให้บริการการกำกับดูแลโครงการสำเร็จรูป

ฉันเคยเห็นปัญหามาก่อน แต่หลังจากนั้นไม่กี่ปีที่ผ่านมาคุณจะได้รับจริงๆเหนื่อยของโครงการเพื่อแก้ปัญหาของฉันคือการออกจากโครงการ มันอาจไม่ได้ผลสำหรับคุณ แต่ปัญหาคือพื้นฐานที่คนอื่นคิดต่างกัน คุณลักษณะที่คุณคิดว่าสำคัญมากนั้นไม่ได้มีความสำคัญต่อผู้อื่น

แผนการที่ดีคือการแบ่งงานของคนอื่น หากคุณสามารถเห็นด้วยกับบุคคลที่เป็นส่วนหนึ่งของโครงการที่อยู่ในความรับผิดชอบของแต่ละคนมีเพียงคนเดียวเท่านั้นที่ทำการตัดสินใจในบางส่วนของโครงการ แต่การทำงานเป็นทีมนั้นยากเสมอ คุณยังคงไม่ชอบการตัดสินใจของโปรแกรมเมอร์คนอื่น ๆ ทางออกที่ดีที่สุดคืออย่ามองสิ่งที่โปรแกรมเมอร์คนอื่น ๆ ตัดสินใจ เพียงแค่เชื่อมั่นในสิ่งที่ถูกต้องก็เพียงพอแล้ว

เป้าหมายทั่วไปจะมุ่งเน้นความพยายามของคุณไปยังสิ่งที่สำคัญ ทุกคนทำงานไปในทิศทางเดียวกันนั้นยากที่จะได้รับและความขัดแย้งจะเกิดขึ้นต่อไป การตัดสินใจร่วมกันต้องมีการรู้ว่าสถานะปัจจุบันของโครงการคืออะไรแล้วตัดสินใจว่าจะต้องอยู่ที่ไหนหลังจากผ่านไประยะหนึ่ง

นี่คือตัวอย่างของสิ่งที่ต้องหลีกเลี่ยง: ตัวอย่างเช่นโปรแกรมเมอร์ c ++ จำนวนมากคิดว่ารหัสที่ไม่ได้ใช้ไลบรารี STL เสียหาย โปรแกรมเมอร์คนอื่น ๆ คิดว่าการพึ่งพาไลบรารีภายนอกทุกครั้งนั้นใช้งานไม่ได้รวมถึง STL ความขัดแย้งดังกล่าวไม่สามารถแก้ไขได้อย่างถูกต้อง - ทั้งสองสถานการณ์ไม่สามารถเติมเต็มพร้อมกันได้ - และคนที่มีปัญหามากที่สุดจะผลักดันความคิดเห็นของพวกเขาไม่ว่าพวกเขาจะพบกับการต่อต้านอะไร

สี่ทางเลือกฉันจะนับ

1. เตะเขาออกไป คุณ (ถูกกล่าวหาว่า) ยังคงเป็นเพื่อนหลักของโครงการนี้ ยกเลิกสิทธิ์การใช้งานแบบกดของเขาและเรียกมันว่าวัน ผลลัพธ์ที่น่าเป็นไปได้มากที่สุดคือเขาฟอร์กโครงการแบ่งชุมชนออกจากกันและจากนั้นสงครามก็พังทลายและเมื่อฝุ่นตกลงมาหนึ่งในส้อมจะได้รับความนิยม
2. แยกมันและดำเนินการต่อที่อื่น ก้าวร้าวน้อยกว่า 1 แต่ผลที่ตามมาจะเหมือนกัน คุณจะต้องมีส่วนร่วมในชุมชนเพื่อดึงผู้คนเข้าหาคุณ
3. ปล่อยให้มันเป็น: ปล่อยให้เขาทำในสิ่งที่เขาทำสงบและหวังให้ดีที่สุด
4. พูดคุยกับชุมชนประนีประนอมตามความจำเป็นและแก้ไขสถานการณ์

โดยส่วนตัวฉันต้องการตัวเลือก 4

Google มีการพูดถึงเทคโนโลยีสองสามครั้งเมื่อไม่กี่ปีที่ผ่านมา ดูพวกเขา:1 ,2 . โดยสังเขป:

1. เข้าใจ : ทำความเข้าใจแรงจูงใจของชุมชนในการทำงานกับโครงการของคุณเทียบกับค่าเสียโอกาสอื่น ๆ ทั้งหมดและรักษาเหตุผลเหล่านั้นไว้
2. เสริมสร้าง : สร้างชุมชนที่มีสุขภาพดีด้วยบรรทัดฐานทางสังคมของความสุภาพความเคารพความไว้วางใจและความอ่อนน้อมถ่อมตน
3. ระบุ : มองหาสัญญาณบอกเล่าเรื่องราวของคนที่มีพิษ (มีรายชื่อมากเกินไป แต่ถ้าคุณถามคำถามนี้คุณอาจรู้หลายคนแล้ว)
4. ฆ่าเชื้อ : สงบและยืนอยู่บนพื้นดินไม่ตอบโต้ต่อการดูถูกความท้าทายการดูหมิ่น ฯลฯ และยืนหยัดในการเสริมสร้างบรรทัดฐานของชุมชน

ร่างเขียนครอบคลุมใช้ได้เกินไปถ้าคุณต้องการที่จะอ่านแทนของนาฬิกา

คุณไม่สามารถลาออกได้โดยไม่พยายามแสดงความกังวลและความยากลำบากของคุณ ฉันรู้ว่ามันอาจเป็นเรื่องยาก ถ้าความจริงถ้าคุณและสมาชิกในทีมของคุณอายุน้อยพอที่จะไม่ได้สัมผัสกับปัญหาสังคมมากมายที่เกิดขึ้นในทีมพัฒนาใด ๆ ก็อาจเป็นเรื่องยากจริงๆ

ต้องบอกว่าฉันเชื่อมั่นว่าคุณควรแสดงความกังวลของคุณ คุณสามารถเขียนลงในอีเมลและแสดงให้เพื่อนที่คุณไว้วางใจซึ่งไม่ได้เป็นส่วนหนึ่งของทีมและไม่สนใจสิ่งที่คุณทำ ในกรณีนี้คุณอาจได้รับการตอบรับที่ดีเพื่อให้ถ้อยคำของอีเมลของคุณไม่รุนแรงเกินไป ติดกับข้อเท็จจริงว่า อย่ากล่าวโทษหรือตำหนิ ข้อเท็จจริงที่ว่ามันยากที่จะทำบางสิ่งให้คุณเพราะ 'blah' หายไป ทำไม 'blah' หายไปควรมีความชัดเจนกับสมาชิกทุกคนในทีมนั่นคือ "โปรแกรมเมอร์ใหม่" ถูกลบหรือไม่ได้ทำอะไรบางอย่าง

อีกครั้งการส่งอีเมลนี้เป็นเรื่องยาก แต่ด้วยตัวเองเป็นประสบการณ์ที่ยอดเยี่ยมที่อาจมีประโยชน์มากสำหรับคุณในอนาคต บทเรียนที่ยอดเยี่ยมในการเรียนรู้

PS: ฉันไม่ได้ตั้งใจฟังเสียงพ่อแม่เกินไป อย่างไรก็ตามเป็นสิ่งที่ฉันจะพูดกับทุกคนรวมถึงลูก ๆ ของฉัน