สูตรคำนวณออร่าทั้งหมด

รวมตัวอักษรที่เพิ่มลบตัวอักษรที่ลบของแต่ละคน ถ้าติดลบให้นับเป็นศูนย์ เพื่อไม่ให้การลบงานของคนอื่นกลายเป็นคะแนนติดลบที่ไปหักคนอื่นต่อ

netChars_i = max(0, Σ(charsAdded) − Σ(charsRemoved))
volume_i   = netChars_i / Σ_j netChars_j

แบ่งช่วงเวลาตั้งแต่เริ่มงานถึงกำหนดส่งเป็น 12 ช่วงเท่ากัน แล้วดูว่างานของแต่ละคนกระจายอยู่ในกี่ช่วง ใช้ normalized Shannon entropy

p_ik          = netChars ของคน i ในช่วง k / netChars ทั้งหมดของคน i
H_i           = − Σ_k p_ik · log(p_ik)      (ข้ามช่วงที่ p = 0)
consistency_i = H_i / log(12)

ทำเรื่อยๆ ทุกสัปดาห์ → entropy สูง → เข้าใกล้ 1 · พิมพ์รวดเดียวคืนก่อนส่ง → entropy ต่ำ → เข้าใกล้ 0

taskShare_i = (จำนวน task ที่ closedBy = i) / (จำนวน task ที่ปิดแล้วทั้งหมด)

ถ้ายังไม่มี task ไหนถูกปิดเลย ระบบให้ทุกคนเท่ากันที่ 1/n เพื่อไม่ให้ส่วนนี้ไปบิดผลลัพธ์

raw_i = volume_i × (0.6 + 0.4 × consistency_i) + 0.2 × taskShare_i
แล้ว normalize raw ให้รวมกันได้ 1

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

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

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

fairShare = 1 / n
aura_i    = round((raw_i − fairShare) × 10000)

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

share_i = raw_i / (1 / n)

share = 1.00 คือทำพอดีส่วนของตัวเอง ไม่ว่าทีมจะมีกี่คน เลขออร่ายังโชว์เหมือนเดิมเพราะมันคือตัวที่คนอ่าน แต่ป้าย tier ตัดสินจาก share

ทำไมไม่ใช้เลขออร่าตัดสิน — เพราะช่วงของออร่าขึ้นกับจำนวนคนในทีม คนที่ไม่แตะงานเลยได้ −10000/n ซึ่งคือ −3,333 ในทีม 3 คน แต่เป็นแค่ −500 ในทีม 20 คน ถ้าตัดสินด้วย threshold คงที่ คนที่ไม่ทำอะไรเลยในทีมใหญ่จะได้ป้าย "พอดีเป๊ะ" ซึ่งพังทั้งระบบ การหารด้วย fair share ทำให้เกณฑ์เท่ากันทุกขนาดทีม และมี test บังคับไว้ที่ทีม 3, 5, 8 และ 20 คน

เรียงค่า raw จากน้อยไปมาก แล้วคำนวณ โดย i เริ่มนับที่ 1

gini = ( Σ_i (2i − n − 1) · raw_i ) / ( n · Σ_i raw_i )

0 คือทุกคนทำเท่ากันเป๊ะ ค่าสูงสุดที่เป็นไปได้คือ (n−1)/n ซึ่งหมายถึงคนเดียวทำทั้งหมด หน้าผลวิเคราะห์วาด Lorenz curve จากค่าชุดเดียวกันนี้ พื้นที่ระหว่างเส้นทแยงกับเส้นจริงคือค่า Gini

elapsedRatio = clamp01( (evaluatedAt − startedAt) / (dueAt − startedAt) )
panicIndex   = gini × elapsedRatio
alertFired   = gini > 0.45 && elapsedRatio > 0.5

สังเกตว่าสูตรใช้ evaluatedAt ที่ติดมากับชุดข้อมูล ไม่ใช่เวลาปัจจุบันของเครื่อง ทั้งระบบไม่มีการเรียก Date.now() หรือ Math.random() ในการคำนวณเลย ผลลัพธ์ของข้อมูลชุดเดิมจึงเท่าเดิมทุกครั้ง ไม่ว่าจะเปิดวันนี้หรืออีกสามเดือน — ระบบวัดที่วัดซ้ำแล้วได้ไม่เท่าเดิม ไม่ใช่ระบบวัด

เงื่อนไข elapsedRatio > 0.5 คือข้อบังคับเชิงจริยธรรมของระบบนี้ เราเตือนตอนผ่านครึ่งทางของ deadline ซึ่งยังแบ่งงานใหม่ได้ ไม่ใช่รอไปประจานตอนส่งงานเสร็จแล้ว

dumpedAtEnd_i = (netChars ของคน i ใน 15% ท้ายของ timeline)
                / (netChars ทั้งหมดของคน i) > 0.6

ตัวนี้จับกรณีที่ปริมาณงานผ่านเกณฑ์แต่มาทีเดียวตอนท้าย ซึ่ง Gini อย่างเดียวมองไม่เห็น เพราะ Gini ดูแค่ว่าใครทำเท่าไร ไม่ได้ดูว่าทำตอนไหน

เส้นแบ่งของระบบนี้ไม่ใช่ "ออนไลน์ กับ ออฟไลน์" และไม่ใช่ "Google กับ Microsoft" เส้นแบ่งจริงคือ เครื่องมือนั้นบันทึกไหมว่าใครแก้อะไรตอนไหน

ทุก adapter ส่งออกหน้าตาเดียวกันคือ (source) => Promise<Edit[]> การเพิ่มแหล่งข้อมูลใหม่จึงไม่ต้องแตะสูตรคำนวณเลย