วิธีจัดการเอกสารของโครงการโอเพ่นซอร์ส [ปิด]


12

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

  • เว็บไซต์ HTML
  • A Github Wiki
  • ไฟล์ Markdown ที่โฮสต์บน Github
  • การวางเอกสารทั้งหมดใน Github README.md

เอกสารถูกเขียนเป็น Markdown แล้วฉันไม่สามารถเข้าใจได้ว่าฉันต้องการให้มันพร้อมใช้งานอย่างไร ฉันชอบ Git มากเพราะฉันสามารถแยกและแท็กเอกสารได้เหมือนกับที่ฉันสามารถแยกและแท็กแหล่งที่มา

ฉันสามารถใช้ห้องสมุด Markdown เพื่อแปล Markdown เป็น HTML และแสดงบนเว็บไซต์ที่มีสไตล์ ฉันจะต้องอัปโหลดการเปลี่ยนแปลงไปยังเว็บไซต์เมื่อใดก็ตามที่มีการเปลี่ยนแปลงและมันยากที่จะจัดการ "แท็ก" ที่แตกต่างกันทั้งหมดของเอกสาร

Github Wikis (เท่าที่ฉันรู้) จะไม่เปลี่ยนแปลงไปตามสาขาที่คุณอยู่ ดังนั้นฉันสามารถมีเอกสาร "รุ่นหลัก" ในรูปแบบ Github Wiki ได้ทุกเวลา

การใส่ทั้งหมดลงใน Github README นั้นค่อนข้างเรียบร้อย ฉันได้รับการแตกแขนงและการแท็ก แต่มันเหนื่อยเล็กน้อยที่จะใช้และไม่ได้ยืมตัวเองได้ดีกับการนำทางที่ง่าย

ฉันไม่มีคำตอบที่ยอดเยี่ยมบ้างไหม? ฉันมีตัวเลือกอื่น ๆ อีกบ้าง?


1
แม้ว่าฉันจะไม่ได้รับคำตอบจริงๆ แต่ฉันก็ได้พบกับโพสต์บล็อกนี้เกี่ยวกับการจัดการเอกสารด้วย wiki github cach.me/blog/2010/12/…คุณอาจพบว่ามีประโยชน์
Jacob Schoen

คำตอบ:


6

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

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

คุณสามารถมี tutorial.h ที่มีกลุ่มข้อความขนาดใหญ่ได้หากคุณต้องการ แต่ให้ถือว่าเป็นส่วนหนึ่งของแหล่งข้อมูล


7
ในความคิดของฉันเอกสารที่สร้างจากไฟล์ต้นฉบับนั้นจำเป็น แต่ไม่ค่อยเพียงพอ เอกสารที่เพียงพอจะต้องมีตัวอย่างที่ไม่สำคัญมากมายตลอดจนบทช่วยสอนทีละขั้นตอน นอกจากนี้เอกสารที่สร้างขึ้นจากซอร์สโค้ดจะดีพอ ๆ กับเอกสารที่ฝังอยู่ในซอร์สโค้ด
Adam Crossland

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

4

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

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

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

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

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


1

ไฟล์ Markdown ที่โฮสต์กับซอร์สนั้นทำงานได้ดีมาก

ตัวอย่างเช่นเครื่องมือdocutils ที่ใช้ RST สามารถสร้าง HTML หรือ LaTex (และ PDF) จากเอกสารหนึ่งชุด

สิ่งนี้มีผล - รวมตัวเลือกของคุณ 1 และตัวเลือก 3


0

หากคุณไม่ทราบการแปลงเอกสารจาก Markdown เพื่อ reStructuredText พิจารณา สฟิงซ์ มันง่ายเหมือนมาร์กดาวน์ แต่มีประสิทธิภาพมากกว่า


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