ความรับผิดชอบของใครเป็นผู้แก้ไขบั๊ก?


12

สถานการณ์ที่เกิดขึ้นหลายครั้งในโครงการโอเพ่นซอร์สจะเป็นดังนี้:

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

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

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

มีมารยาทมาตรฐานในสถานการณ์เหล่านี้หรือไม่? พวกเขาจะแก้ไขได้อย่างไร? ปฏิกิริยาของฉันผิดปกติหรือไม่ คุณคาดหวังว่าจะได้รับการแก้ไขข้อบกพร่องนานแค่ไหน?

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

คำตอบ:


12

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

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

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


ตกลง 100% ไม่มีความรับผิดชอบในผู้ใช้ปลายทางที่จะส่งการแก้ไขโดยตรงไปยังแหล่งเก็บข้อมูลยกเว้นว่าคุณต้องการเป็นผู้มีส่วนร่วมประจำโครงการ นั่นคือสิ่งที่รายการส่งจดหมายและเครื่องมือติดตามข้อบกพร่องมีไว้สำหรับ Spring, Maven และอื่น ๆ ทำโมเดลที่ตรงนี้ซึ่งผู้คนจะค้นหาวิธีแก้ปัญหาด้วยตนเองและโพสต์ลงในรายการใน Jira มันเกินกว่าที่ใครก็ตามที่ทำงานกับข้อผิดพลาดเพื่อยอมรับและจัดการกับผลงาน
Spencer Kormos

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

สมมติว่าผมรู้สึกมีส่วนร่วมกับโครงการโดยรวม อะไรที่เปลี่ยนแปลง
Steve Bennett

@SteveBennett โดยไม่ทราบถึงโครงสร้างของโครงการฉันไม่สามารถตอบได้ บางโครงการมีโครงสร้างที่เข้มงวดมากขึ้นกับงานที่ได้รับมอบหมายในขณะที่โครงการอื่น ๆ จะไหลลื่นมากขึ้น
โธมัสโอเวนส์

5

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

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

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


4

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

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

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


2

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

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


1

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

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


1

สำหรับนักพัฒนาซอฟต์แวร์โอเพนซอร์สมีปัญหาสองประเภท:

  • (a) ปัญหาโดยไม่มีโปรแกรมแก้ไข
  • (b) ปัญหาที่เกิดจากโปรแกรมแก้ไข

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

อย่างไรก็ตามเป้าหมายหลักของพวกเขาคือการลดจำนวนปัญหาประเภท b นั่นเป็นสาเหตุที่ทำให้บาร์ตั้งค่าค่อนข้างสูง

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

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

ผลลัพธ์ที่ได้นั้นคุ้มค่าอย่างยิ่ง สิ่งที่สามารถพูดว่า "ฉันรหัสได้หรือไม่ใช่ ... คุณกำลังใช้สิ่งที่ฉันเขียนทุกวัน"


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

มีการกล่าวถึงแล้วว่าการเปิดตัวครั้งต่อไปจะไม่รวมโปรแกรมแก้ไขในเครื่องของคุณ - ดังนั้นจึงเป็นเรื่องที่ดีที่สุดที่คุณจะได้รับการแก้ไขในซอฟต์แวร์ บริษัท ที่ชาญฉลาด - เป็นประโยชน์สูงสุดของ บริษัท เช่นกันในวันหนึ่งคุณอาจออกไปและไม่มีใครจำได้ว่าจะต้องทำการแก้ไขแอปพลิเคชั่น XYZ อีกครั้งพร้อมกับการแก้ไขในเครื่องของคุณ ลองสิ่งนี้: ทำใหม่แพทช์ แต่อย่าส่ง ส่งไปยังผู้ดูแลทางอีเมลหรืออย่างอื่น - และถามข้อเสนอแนะของพวกเขา - ในขณะที่ "ฉันคิดว่าฉันมีทุกอย่างที่คุณพูดถึง - คุณสามารถช่วยฉันให้แน่ใจว่าสิ่งนี้ถูกต้องหรือไม่"
pbr
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.