3 คะแนน โดย GN⁺ 2024-01-15 | 2 ความคิดเห็น | แชร์ทาง WhatsApp
  • PostHog ดำเนินการ Slack แบบสาธารณะเป็นศูนย์กลางคอมมูนิตี้มานาน 4 ปี แต่เมื่อขนาดเกิน 5,000 คน ข้อจำกัดด้านการค้นหา การเชื่อมโยงกับการซัพพอร์ต และการเก็บรักษาบันทึกก็ชัดเจนขึ้น จึงย้ายไปยังฟอรัมของตัวเอง
  • ฟอรัมใหม่นี้สร้างอยู่ภายในเว็บไซต์ PostHog และมีผู้ใช้งานแล้ว มากกว่า 1,500 คน โดยเน้นการเก็บคำถามและคำตอบให้เป็นองค์ความรู้ด้านซัพพอร์ตระยะยาว
  • แผนเสียเงินของ Slack มีค่าใช้จ่าย $7.25+ ต่อผู้ใช้ต่อเดือน และแม้จะพิจารณา บอต AI ของตัวเอง ด้วย แต่ PostHog เลือกสร้างฟอรัมเองโดยใช้ headless CMS บน Strapi
  • Slack แบบสาธารณะจะเก็บช่องทั้งหมดเข้า archive ในวันที่ 12 มกราคม 2024 เพื่อปิดการเริ่มหัวข้อสนทนาและการตอบใหม่ จากนั้นมีแผนปิดถาวรและลบคอนเทนต์เดิมออก; ใน TL;DR ระบุวันที่ 24 มกราคม แต่ในคำอธิบายกำหนดการระบุเป็น 22 มกราคม
  • การเปลี่ยนแปลงครั้งนี้ใช้กับ Slack แบบสาธารณะเท่านั้น โดยช่องแบบ private ของผู้ใช้ซัพพอร์ตแบบเสียเงินผ่าน Slack Connect, ระบบช่วยเหลือในแอป และกิจกรรมใน GitHub repository จะยังคงอยู่ต่อไป

เหตุผลที่ปิด Slack แบบสาธารณะ

  • PostHog เติบโตในฐานะโปรเจ็กต์โอเพ่นซอร์ส และนับตั้งแต่เปิดตัวก็ได้รับโค้ดจากผู้มีส่วนร่วม มากกว่า 500 คน พร้อมทั้งแลกเปลี่ยนไอเดียกับผู้ใช้หลายพันคนผ่าน Slack แบบสาธารณะ
  • ตลอด 4 ปีที่ผ่านมา Slack แบบสาธารณะเป็นพื้นที่ศูนย์กลางสำหรับบทสนทนาของผู้ใช้ การรวบรวม feature request การตอบคำถาม และการรับฟังฟีดแบ็ก
  • เมื่อคอมมูนิตี้ขยายเกิน 5,000 คน ข้อจำกัดของ Slack ในฐานะแพลตฟอร์มซัพพอร์ตก็เด่นชัดขึ้น
    • ข้อความหายไปจากประวัติแชตอย่างรวดเร็ว
    • แยกขาดจาก flow การซัพพอร์ตหลักของ PostHog
    • วิธีแก้ปัญหาที่มีประโยชน์ไม่สามารถค้นหาได้บนเว็บไซต์ PostHog หรือ Google
  • PostHog พิจารณาทั้งแผนเสียเงินของ Slack และ บอต AI ของตัวเอง เป็นทางออก แต่สุดท้ายตัดสินใจว่าจำเป็นต้องใช้แนวทางใหม่
    • แผนเสียเงินของ Slack มีค่าใช้จ่าย $7.25+ ต่อผู้ใช้ต่อเดือน

โครงสร้างของฟอรัมคอมมูนิตี้ที่สร้างเอง

  • แทนที่จะใช้แพลตฟอร์มฟอรัมแบบเดิมอย่าง vBulletin หรือ phpBB, PostHog เลือกใช้ Strapi เป็น headless CMS เพื่อสร้างฟอรัมของตัวเอง
  • ฟอรัมใหม่นี้เปิดใช้งานมาหลายเดือนเพื่อปรับแก้ปัญหาต่าง ๆ และปัจจุบันมี สมาชิกที่ใช้งานอยู่มากกว่า 1,500 คน
  • ฟอรัมคอมมูนิตี้ของ PostHog เป็นพื้นที่เฉพาะสำหรับโพสต์คำถามถึงทีม PostHog และคอมมูนิตี้วงกว้าง
    • ใครก็สามารถตอบได้
    • สามารถเลือกคำตอบหนึ่งข้อเป็น วิธีแก้ที่ต้องการ ได้
    • คำตอบที่ถูกเลือกจะกลายเป็นแนวทางสำหรับผู้ใช้ที่เจอปัญหาเดียวกันในภายหลัง
  • คอนเทนต์ในฟอรัมเชื่อมโยงเข้ากับ flow การซัพพอร์ตหลักของ PostHog อยู่บนเว็บไซต์อย่างถาวร และสามารถถูกค้นพบโดยเสิร์ชเอนจิน

ประสบการณ์คอมมูนิตี้ที่เชื่อมกับเอกสารและโปรไฟล์

  • ฟอรัมนี้ยังผสานเข้ากับส่วนอื่น ๆ ของเว็บไซต์ PostHog ด้วย
  • ผู้ใช้สามารถโพสต์คำถามได้ทันทีขณะอ่านเอกสารของ PostHog และคำถามจะถูกรวบรวมอัตโนมัติเป็นหมวดหมู่ที่จัดเรียงได้
    • หากกำลังทำตามคู่มือแล้วพบว่าคำอธิบายยังไม่เพียงพอ ก็สามารถทิ้งคำถามไว้ให้ PostHog เข้ามาตรวจสอบได้
  • โปรไฟล์ถูกออกแบบให้เป็นฟังก์ชันศูนย์กลางสำหรับติดตามการมีส่วนร่วมในคอมมูนิตี้
    • เพิ่มข้อมูลผู้ใช้
    • ติดตามการสนทนาที่เข้าร่วม
    • แสดง ความสำเร็จ ที่ได้รับจากคอมมูนิตี้
  • ผู้ใช้ที่ย้ายจาก Slack แบบสาธารณะมาสู่คอมมูนิตี้ของ PostHog จะได้รับความสำเร็จเฉพาะตัวในคอมมูนิตี้เพื่อเป็นการขอบคุณ
  • โปรไฟล์สามารถเปิดในรูปแบบ Ask Me Anything ได้ โดย James, Cory, โปรไฟล์ของผู้เขียน ใช้งานฟังก์ชันนี้อยู่แล้ว

กำหนดการปิด Slack และการย้ายบัญชี

  • แม้จะมีทางเลือกในการเปิด Slack แบบสาธารณะควบคู่กับฟอรัม แต่ PostHog เลือกย้ายไปใช้ฟอรัมเพื่อไม่ให้ผู้ใช้อยู่ในสภาพก้ำกึ่ง
  • ปัจจุบันการเข้าร่วมคอมมูนิตี้ยังต้องสร้างบัญชีแยกต่างหาก แต่ในอนาคตมีแผนจะรวมเข้ากับบัญชี PostHog ปกติ
  • กำหนดการของ PostHog Slack แบบสาธารณะมีดังนี้
    • 12 มกราคม 2024: เก็บทุกช่องใน Slack แบบสาธารณะเข้า archive เพื่อปิดการโพสต์หัวข้อสนทนาใหม่และการตอบกลับใหม่
    • ช่วงเวลานี้เปิดโอกาสให้ย้ายบทสนทนาที่ยังค้างอยู่ไปยังที่ใหม่ เช่น คอมมูนิตี้ของ PostHog
    • หลังจากนั้นมีแผนจะปิดกลุ่ม Slack อย่างถาวรและลบคอนเทนต์เดิม
  • การระบุวันที่ในเนื้อหามีความไม่ตรงกัน
    • ใน TL;DR ระบุว่าวันปิด Slack แบบสาธารณะคือ 24 มกราคม 2024
    • ในคำอธิบายกำหนดการ ระบุว่าวันปิดถาวรคือ 22 มกราคม 2024

ช่องทางซัพพอร์ตที่ยังคงเดิม

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

2 ความคิดเห็น

 
xguru 2024-01-15

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

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

 
GN⁺ 2024-01-15
ความคิดเห็นบน Hacker News
  • หวังว่านี่จะเป็น จุดเริ่มต้นของกระแส นะ การต้องพึ่งบุคคลที่สามเพื่อจัดการการสื่อสารกับบุคคลที่สองมันรู้สึกไม่ค่อยสบายใจ และการตั้งค่า Slack ก็รกโดยไม่จำเป็นด้วย
    Discord ยิ่งแย่กว่าในเรื่องนี้

    • ผมก็อยากให้มันกลายเป็นกระแสเหมือนกัน แต่เหตุผลต่างออกไปนิดหน่อย บริการแบบนี้เอาข้อมูลไปขังไว้หลัง กำแพงล็อกอิน และไม่ให้เสิร์ชเอนจินเข้าถึง ทำให้คนที่เพิ่งเข้ามาหาข้อมูลที่ต้องการบนออนไลน์ได้ยากมาก
      ถ้าฟอรัมกลับมาเป็นมาตรฐานอีกครั้ง และบริหารอย่างสมเหตุสมผลให้แขกก็อ่านได้ ข้อมูลที่มีประโยชน์ก็จะกลับมาหาเจอทางออนไลน์ได้อีก
    • Discord เป็นตัวเลือกที่แย่เป็นพิเศษ อย่างน้อยที่สุด การค้นหาก็ห่วย และทันทีที่ Discord หรืออัลกอริทึมอัตโนมัติตัดสินใจ เนื้อหาทั้งหมดอาจหายไปด้วยเหตุผลอะไรก็ได้
    • Discord ใช้ลำบากที่สุด ผมมี Slack workspace เกิน 30 อัน แต่ในดีไซน์ใหม่สามารถซ่อนทุกอย่างไว้ เหลือเฉพาะอันที่อยู่ในบริบทปัจจุบันได้ เลยดีกว่า UI เดิม
      Discord ยังไม่มีฟีเจอร์แบบนี้ และพอผมอยู่ในเซิร์ฟเวอร์ Discord เกิน 100 เซิร์ฟเวอร์ การแจ้งเตือนก็กลายเป็นฝันร้ายสุด ๆ แถมหาเซิร์ฟเวอร์ที่ต้องการก็แทบเป็นไปไม่ได้
    • สำหรับการสื่อสารแบบแชตที่ไม่ถูกผูกกับบริษัทแสวงกำไร Matrix เป็นตัวเลือกที่ obvious
    • เห็นด้วย 100% อย่างน้อยใช้ GitHub Discussions ก็ยังดีกว่า
  • อยากให้ผลิตภัณฑ์ซอฟต์แวร์ทุกตัวทำแบบนี้ แอปแชตเหมือน ลานสาธารณะที่วุ่นวาย ที่ทุกคนตะโกนใส่ฝูงชน ข้อมูลสำคัญอยู่ไม่พ้นชั่วขณะ
    ในทางกลับกัน ฟอรัมสนทนาจะกลายเป็นห้องสมุดสาธารณะที่เก็บรักษาข้อมูลและทำให้ค้นหาได้เมื่อเวลาผ่านไป แน่นอนว่าต้องอยู่บนเงื่อนไขว่าเสิร์ชเอนจินเข้าถึงข้อมูลนั้นได้

    • เวลาเห็น ลิงก์ Discord สำหรับซัพพอร์ตหรือคอมมูนิตี้แล้วหงุดหงิดจริง ๆ
    • แชตกับฟอรัมมีการใช้งานคนละแบบ แชตเหมาะกับบทสนทนาแบบทันทีและโต้ตอบกันเพื่อช่วยเหลือคนเฉพาะราย ส่วนฟอรัมหรือ Stack Overflow เหมาะกับข้อมูลแบบอะซิงโครนัส อัปเดตได้ และนำกลับมาใช้ซ้ำได้สำหรับผู้อ่านในอนาคตที่มาจาก Google มากกว่า
      ถ้าเอาสองอย่างมาปนกัน เป้าหมายจะขัดกันและความคาดหวังไม่ตรงกันจนเกิดความผิดหวัง เรื่องแบบนี้เกิดใน Stack Overflow ด้วยเมื่อมีคนคาดหวังให้มันเป็นแบบแรก
    • ฟอรัมสนทนาก็มักกลายเป็น หลุมดำ ในแง่การจัดเก็บและจัดระเบียบข้อมูลเหมือนกัน อาจมีข้อดีข้อเสียเมื่อเทียบกับห้องแชต แต่ผมไม่คิดว่ามันเป็นสิ่งที่ควรมุ่งใช้เป็นที่เก็บและจัดระเบียบข้อมูล
    • สงสัยว่าไม่เคยใช้ ฟังก์ชันค้นหา ของ Slack หรือ Discord หรือเปล่า
      ไม่ว่าจะฟอรัมหรือแชต โครงสร้างข้อมูลโดยรวมก็คล้ายกัน และโดยเฉพาะ Slack/Discord ก็มีเธรดด้วย
  • เหตุผลที่ฟอรัมกลับมาแล้วดี ก็แค่เพราะ ค้นหาได้
    ปัญหาคือพอผู้ใช้หลั่งไหลเข้ามา เสียงรบกวนจะเยอะเกินไป อาจกลายเป็นอีกวัฏจักรหนึ่งที่อีกไม่กี่ปีก็กลับไป Slack/Discord แล้วอีกไม่กี่ปีถัดมาก็กลับมาฟอรัมอีก

    • การค้นหาของ Discord แย่มาก แชตกับเธรดก็โอเค แต่หาข้อความเก่า ๆ ยาก
      ดูเหมือนมีโอกาสสร้างบริการที่เป็นแพลตฟอร์มคล้ายกันแต่ ค้นหาได้ดีกว่ามาก
    • ผมมองว่าฟอรัมกับ Slack/Discord/IRC ใช้กับการสื่อสารคนละประเภทกัน ฟอรัมเป็นแบบอะซิงโครนัสมากกว่า ส่วนที่เหลือซิงโครนัสมากกว่า
      ถ้าช่วยแก้ปัญหาในฟอรัม จะเหลือเธรดบทสนทนาที่ค้นหาและตามอ่านได้ แต่ใน Slack/Discord/IRC เนื้อหาแบบนี้ให้ความรู้สึกเหมือนหายไป ต่อให้มีล็อกที่ค้นหาได้ ก็ยังหายากกว่าฟอรัมที่มีโครงสร้างมากกว่าเยอะ
      การมีทั้งฟอรัมและ Slack/Discord/IRC นั้นมีคุณค่า
    • กังวลว่า สแปม จะทำลายความพยายามนั้น กำลังดูแลฟอรัมที่ค่อนข้างดีบน Google Groups อยู่ แต่ช่วงหลังโดนโจมตีด้วยสแปม เลยต้องจำกัดสิทธิ์โพสต์ค่อนข้างเข้มเพื่อป้องกัน
    • ช่วงหลังผมมีปัญหาในการหาข้อความเก่า แล้วก็พบว่าถ้าเปิด โหมดสตรีมเมอร์ อยู่ ฟังก์ชันค้นหาและฟิลเตอร์จำนวนมากจะถูกบล็อก
      ไม่รู้ว่าทำไมโหมดสตรีมเมอร์ถึงเปิดอยู่ แต่ก็คุ้มที่จะลองเช็กว่ามีอาการเดียวกันไหม
    • พูดตรง ๆ ผมคิดว่าปัญหาตรงข้ามเกิดบ่อยกว่า หลายที่ต่างเปิดฟอรัมเล็ก ๆ ของตัวเอง แต่แทบไม่มีกิจกรรม
      กลยุทธ์แบบ IRC ที่มีเน็ตเวิร์กและมีแชนเนลอยู่ข้างในนั้นก็ดี แบบนั้นคอมมูนิตี้ของภาษาโปรแกรมส่วนใหญ่ก็จะกลายเป็น “อยู่ในเน็ตเวิร์กนี้ก็พอ” Reddit เป็นรูปแบบที่ขยายสิ่งนี้ขึ้น 1000 เท่าในแง่ที่มี subreddit อยู่ในแพลตฟอร์มเดียวกัน
      แม้จะไม่สมบูรณ์แบบด้วยหลายเหตุผล แต่การต้องสมัครฟอรัมแบบสุ่มเพื่อรับซัพพอร์ตจากที่อย่าง Circle CI นั้นก็รู้สึกตลกอยู่เสมอ
  • Laravel ทำสิ่งนี้ผ่าน ฟอรัม Laracasts และทำได้ยอดเยี่ยม เวลาหาคำตอบเกี่ยวกับ Laravel ที่นั่นเป็นที่แรกที่ไปก่อน ChatGPT หรือ Stack Overflow
    ถ้าเป็นเรื่องค้นหาเนื้อหาในอดีต ไม่มีอะไรสู้ฟอรัมสาธารณะที่ดูแลดีได้

    • ผมก็ทำแบบเดียวกันเวลาหาคำตอบเกี่ยวกับ TrueNAS หรือ Proxmox
  • สำหรับผม Reddit โดยพื้นฐานแล้วคือฟอรัมที่ชอบใช้ เวอร์ชัน “old” ใกล้เคียงกับฟอรัมจริง ๆ
    ถ้าเอา subreddit หลาย ๆ อันมาต่อกัน ก็พอจำลองประสบการณ์ฟอรัมแบบเก่าได้ระดับหนึ่ง หนึ่งในสิ่งที่ผมดูทุกวันมีประมาณนี้
    https://old.reddit.com/r/AZURE+CCDE+Intune+PowerShell+ccnp+m...
    ไม่ใช่ดีที่สุด แต่โดยรวมก็ทำงานที่ต้องการได้

    • ผมไม่เคยเข้าใจเลยว่าทำไมฟอรัมหรือเอนจินขนาดใหญ่ในอดีตถึงไม่ค่อยบรรจบไปสู่โครงสร้างแบบ Reddit มากกว่านี้ อย่างฟีเจอร์สมัครติดตามเธรดเฉพาะและมี หน้าจอเริ่มต้นแบบปรับแต่งเอง อะไรทำนองนั้น
  • อยากให้ใครสักคนทำ ธีม phpBB หรือ vBulletin ที่เวลาเข้าสู่ระบบแล้วดูเหมือน Slack และเวลาออกจากระบบแล้วดูเหมือน Pinterest/Instagram/TikTok
    การย้ายคนจำนวนมากกลับมาฟอรัมไม่น่าจะยากขนาดนั้น เพียงแต่หวังว่าเธรดและเครื่องหมายแนะนำจะแสดงผลต่างออกไปบนมือถือ

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

    • ฟอรัม/เมลลิงลิสต์ กับ Slack/Discord/IRC เป็นการสื่อสารคนละแบบกัน แบบแรกเป็นอะซิงโครนัสและใกล้เคียงออฟไลน์มากกว่า ส่วนแบบหลังเป็นซิงโครนัสและใกล้เคียงออนไลน์มากกว่า
      ทั้งสองอย่างสามารถอยู่คู่กันได้ในโปรเจกต์หรือคอมมูนิตี้เดียวกัน ถ้าต้องการติดตามคำถามและคำตอบเฉพาะเรื่อง ฟอรัมดีกว่ามาก แต่การคุยเล่นก็มีประโยชน์ได้เช่นกัน และเครื่องมืออย่าง IRC ก็เหมาะกับการใช้งานแบบนั้นมากกว่า
  • ตามบทความ ระบุว่าพวกเขาตัดสินใจสร้างฟอรัมเองโดยใช้ Strapi เป็น headless CMS แทนแพลตฟอร์มฟอรัมสำเร็จรูปอย่าง vBulletin หรือ phpBB
    ฝากลิงก์ไว้สำหรับคนที่รีบ
    https://strapi.io/

    • ไม่เข้าใจว่าทำไมต้องสร้างเอง ซอฟต์แวร์ฟอรัมเป็นเรื่องที่มีทางออกอยู่แล้ว จึงรู้สึกเหมือนเป็น การสิ้นเปลืองทรัพยากร
  • แม้จะบอกว่า “ไม่สามารถค้นหาโซลูชันที่มีประโยชน์ในเว็บไซต์ของเราหรือบน Google ได้” แต่ฟอรัมนั้น ไม่เรนเดอร์หากไม่มี JavaScript ดังนั้นก็ยังมีแนวโน้มว่าจะไม่ถูกเก็บใน archive.org และค้นหาไม่ได้ใน Bing หรือ DuckDuckGo

    • บล็อกเองก็ดูเหมือนจะพึ่งพา JavaScript ในการเรนเดอร์ข้อความด้วย เซสชันส่วนใหญ่น่าจะมีปฏิสัมพันธ์จากผู้ใช้แทบไม่มีนอกจากการเลื่อนหน้า ดังนั้นการสร้าง HTML แล้วเสิร์ฟแบบสแตติกดูเหมือนจะเป็นตัวเลือกที่ควรทำอยู่แล้ว
    • เมื่อถูกเก็บถาวรแล้วก็ทำงานได้ดี ตัวอย่างเช่น
      https://web.archive.org/web/20240114085417/https://posthog.c...
    • นี่เป็นอีกเหตุผลหนึ่งที่ควรเลิกใช้ SPA กับคอนเทนต์เชิงข้อมูลอย่างฟอรัมหรือการสนทนา แล้วหันไปใช้ สถาปัตยกรรมแบบ islands หรือหน้าเว็บที่ไม่ต้องพึ่ง JavaScript
      อย่างน้อยการแสดงข้อมูลบนเว็บก็ไม่ควรพึ่งพา JavaScript
  • ดูแปลกที่ตัวเลือกที่เหมาะกับ PostHog คือการทำฟอรัมด้วย CMS แล้ว โฮสต์เอง
    น่าจะมีโซลูชันฟอรัมแบบโฮสต์ที่เทียบได้กับ Slack อย่าง Discourse อยู่ไม่ใช่หรือ?

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