diff --git a/Docs/Proposals/2026-10-31-criteria-stars-pros-cons.html b/Docs/Proposals/2026-10-31-criteria-stars-pros-cons.html new file mode 100644 index 00000000..f8a371f8 --- /dev/null +++ b/Docs/Proposals/2026-10-31-criteria-stars-pros-cons.html @@ -0,0 +1,394 @@ + + + + + + + Sao theo tiêu chí và ưu nhược + + + +
+ Đề xuất thiết kế + Cần JOY quyết +

Sao theo từng tiêu chí, ưu nhược điểm cho mỗi review, và điểm giá trị review

+

Ngày 31/10/2026. Người soạn: Core (Rate). Issue #1531 (thiết kế sao theo tiêu chí, ưu nhược điểm, điểm giá trị review). Đồng thời giải quyết #1143 (điểm tiêu chí suy ra từ số sao nên dồn về 5.00) và câu hỏi "một con số điểm" của #1470 (PR #1478 đang giữ). Đây chỉ là thiết kế: chưa sửa code, chưa đụng database.

+ +

0. Tóm tắt trong một phút

+ + +

Quy ước và từ ngữ. Công thức và bảng dùng dấu phẩy thập phân (4,2); con số hiện cho người mua dùng dấu chấm như trên rate.vn hiện nay (4.6). "Seeding": review được trả tiền hoặc dàn dựng để khen. "Cổng chặn": điều kiện đưa trọng số review về 0 (giả, chép, viết cho có). "Cận dưới Wilson": cách tính tỷ lệ vote hữu ích có tính đến việc ít vote thì kém chắc chắn, nên 2 vote trên 2 không thắng 90 vote trên 100. "Pipeline": chuỗi bước xử lý chạy tự động theo đợt.

+ +

1. Hiện trạng (đọc code, chỉ đọc)

+
+ + + + + + + + + +
PhầnĐang cóThiếu hoặc sai
Chấm tiêu chí khi viết reviewForm trong JReviewsSection.tsx có 5 hàng nút chọn 1 đến 5 sao (screen, performance, camera, battery, value), mặc định 5 sao. Số sao của review là trung bình cộng, làm tròn thành số nguyên. API POST /api/v1/rate/reviews lọc khoá tiêu chí rồi gọi RPC rate.submit_community_review, lưu vào cột rate.reviews.criteria_ratings (jsonb). RPC không kiểm khoá.Cùng 5 tiêu chí cho mọi ngành hàng (tai nghe chỉ đổi nhãn). Không có trọng số. Tiêu chí người viết không bấm vẫn tính 5 sao. API tin số sao tổng trình duyệt gửi lên, chỉ tự tính khi thiếu. Cột rating_star là số nguyên 1 đến 5. Không có ưu nhược trên review.
Điểm tiêu chí của sản phẩmcomputeJReviewsCriteriaScores trong leaderboard-engine.ts: đọc expert_criteria_scores, nếu không có thì lấy số sao cộng một độ lệch tự đặt theo thông số và giá.Chính là lỗi #1143: điểm bịa, dồn về 5.00, hoà và thứ hạng giả. Điểm tiêu chí bịa này còn chiếm 20% điểm ghép của bảng xếp hạng. Trong repo này không có code nào ghi expert_criteria_scores; 36 sản phẩm có điểm chuyên gia từ file seed (đề xuất kiểm tra nguồn gốc catalog ngày 16/10).
Điểm tổngTrang sản phẩm dùng điểm Bayes (#1144: k = 3, trung bình mặc định 4,2), web tính từ danh sách review. Database chỉ lưu user_rating_weighted: trung bình có trọng số, không Bayes. Bảng xếp hạng dùng một điểm ghép (người dùng, chuyên gia, tiêu chí).Lỗi #1470: cùng một máy hiện 4.8, 4.98, 5.0 ở các chỗ khác nhau.
Trọng số reviewTrọng số đang lưu (helpfulness_weight, 0 đến 3) do rate.compute_review_weight tính: gốc 1 (0,25 nếu đáng ngờ, 0 nếu giả), cộng trừ theo vote và báo cáo. Mô hình tin cậy review (Docs/Platform/review-trust-model.html) đã thiết kế công thức sáu trục w = G × A × B × C × D × E × F, nhưng chưa được dùng cho trọng số đang lưu.Chưa có gì đo "review có đủ ưu nhược, đủ tiêu chí không".
Ưu nhượcAI trong importer (ai-review-analyzer.ts) sinh tối đa 6 ưu và 6 nhược cho cả một listing, lưu ở rate.review_analysis.pros/cons; web gộp theo sản phẩm và hiện.Không theo tiêu chí, không đếm số người nhắc, không gắn với review nào. Schema zod review.schema.ts có trường pros/cons nhưng không dùng.
Vote hữu íchCó, kèm điều kiện tài khoản 7 ngày, đã xác minh email hoặc số điện thoại, giới hạn 60 lượt mỗi giờ.Ổn, dùng lại được.
Điểm thưởng cho người dùngChưa có hệ thống nào.Cần quyết riêng (mục 9, D8).
"Tiêu chuẩn 10 nhóm"10 nhóm thông số (màn hình, phần cứng, pin, camera...) trong specs.schema.ts và spec-template.ts.Là nhóm thông số kỹ thuật, không phải tiêu chí chấm sao. Tiêu chí chấm sao sẽ tham chiếu tới nhóm thông số liên quan, nhưng là danh sách riêng.
+ +

2. Mô hình tiêu chí

+

2.1 Danh sách tiêu chí và trọng số theo ngành hàng (bản nháp)

+

Trọng số mỗi ngành cộng lại bằng 100. Đây là bản nháp để JOY sửa; con số chỉ là điểm xuất phát.

+
+ + + + + + + +
Ngành hàngTiêu chí (trọng số %)
Điện thoạiHiệu năng 20, Camera 20, Pin và sạc 20, Màn hình 15, Thiết kế và độ bền 10, Đáng tiền 15
Máy tính bảngMàn hình 20, Hiệu năng 20, Pin 15, Loa và giải trí 10, Phần mềm và phụ kiện 10, Thiết kế 10, Đáng tiền 15
LaptopHiệu năng 25, Màn hình 15, Pin 15, Bàn phím và touchpad 10, Tản nhiệt và độ ồn 10, Thiết kế và độ bền 10, Đáng tiền 15
Đồng hồ thông minhTheo dõi sức khoẻ 25, Pin 20, Thiết kế và đeo 15, Ứng dụng và kết nối 15, Màn hình 10, Đáng tiền 15
Tai ngheChất âm 30, Chống ồn 15, Pin 15, Đeo thoải mái 15, Mic và gọi 10, Đáng tiền 15
Dịch vụ (khi mở, entity_type = 'service')Chất lượng dịch vụ 35, Giá cả 25, Thái độ phục vụ 20, Tốc độ 20
+ + +

2.2 Cách tính

+

Điểm tổng của một review trên Rate, tính như JReviews, người viết không tự chọn số sao tổng:

+
sao_review = Σ (trọng_số_i × sao_i) / Σ trọng_số_i      chỉ trên các tiêu chí người viết đã chấm
+làm tròn 0,1; người viết thấy con số này ngay khi kéo sao
+

Người viết được bỏ qua tối đa 2 tiêu chí ("Chưa dùng tới", ví dụ chưa thử chống ồn), không được bỏ "Đáng tiền". Không còn mặc định 5 sao: tiêu chí chưa bấm thì form báo thiếu, chứ không tự tính là 5.

+

Điểm từng tiêu chí của sản phẩm (Bayes theo từng tiêu chí, cùng cách #1144 đang dùng cho điểm tổng):

+
điểm_tiêu_chí_i = (k × μ_i + Σ w_r × sao_r,i) / (k + Σ w_r)
+k = 3; μ_i = trung bình tiêu chí i của cả ngành hàng (chưa có thì 4,2)
+w_r = trọng số tin cậy của review r (mô hình tin cậy review, 0 đến 3)
+chỉ tính review có chấm tiêu chí i và có trọng số lớn hơn 0
+hiện khi có ít nhất 3 người viết khác nhau và Σ w_r ≥ 1,5; còn lại "Chưa đủ dữ liệu"
+dùng để xếp hạng theo tiêu chí (chip "#1 Màn hình") khi có ít nhất 5 người viết khác nhau
+

Ngưỡng theo số người viết là để một review được vote cao không tự tạo ra một thứ hạng.

+

Điểm tổng của sản phẩm (con số duy nhất hiện mọi nơi):

+
điểm_sản_phẩm = (k × μ + Σ w_r × sao_review_r) / (k + Σ w_r)      k = 3, μ = 4,2 (như #1144)
+mọi review hợp lệ: review Shopee dùng số sao gốc, review Rate dùng sao_review tính ở trên
+

Vì sao không tính điểm sản phẩm thẳng từ các điểm tiêu chí: review lấy từ sàn (phần lớn dữ liệu hiện nay) chỉ có một số sao tổng. Tính từ tiêu chí sẽ bỏ hết số review đó, và sản phẩm chưa có review Rate nào sẽ không có điểm. Trọng số tiêu chí vẫn quyết định điểm tổng, nhưng ở bên trong từng review Rate. Khi review Rate đủ nhiều, hai cách cho kết quả gần nhau; Core sẽ theo dõi chênh lệch này.

+

Hệ quả cần nói rõ trên trang: điểm chính (tính từ mọi review) có thể khác trung bình có trọng số của các điểm tiêu chí (chỉ từ review Rate). Vì vậy khối điểm tiêu chí ghi "Từ N review trên Rate" và có link "cách tính điểm". Đây là hai con số đo hai thứ khác nhau, có nhãn, không phải lỗi #1470.

+ +

2.3 Giải quyết #1143 (điểm tiêu chí dồn về 5.00)

+ + +

2.4 Giải quyết #1470 (một con số điểm)

+ + +

3. Mô hình dữ liệu

+

Mọi thay đổi bảng dưới đây là DDL trên Supabase dùng chung, nên đi qua migration DOS-Me do JOY duyệt và chạy. Repo này chỉ soạn đề xuất SQL, không áp dụng.

+
+ + + + + + + + +
ChỗThay đổiCó sẵn hay mớiMigration
rate.reviews.criteria_ratingsGiữ dạng {khoá: sao}, thêm khoá mới theo danh sách ngành hàng.Có sẵnKhông (API kiểm khoá theo danh sách mới)
rate.reviews.rating_starĐang là số nguyên 1 đến 5 (SMALLINT), RPC cũng nhận số nguyên. Số sao tính từ tiêu chí là số lẻ (4,3), nên thêm cột rating_exact numeric(2,1); rating_star giữ số làm tròn cho code cũ đọc. Các hàm tính điểm đọc rating_exact khi có.Có sẵn, thêm cột cạnh nóCó, DOS-Me
rate.reviews cột mớiverdict text (câu kết luận, tối đa 300 ký tự); criteria_version int; value_score numeric(5,2) và value_breakdown jsonb (mục 6).MớiCó, DOS-Me
rate.review_points (bảng mới)Mỗi dòng là một ưu hoặc nhược: review_id, criterion_key (rỗng nghĩa là ưu nhược chung của review), kind ('pro' hoặc 'con'), body (5 đến 150 ký tự), position, cluster_id (do bước gom gán).MớiCó, DOS-Me
rate.product_points (bảng mới)Kết quả gom cho mỗi sản phẩm: master_id, criterion_key, kind, label (câu hiển thị), support (tổng trọng số người nhắc), reviewer_count, has_expert, first_seen, last_seen, method ('code' hoặc 'ai').Mới; thay dần review_analysis.pros/consCó, DOS-Me
rate.master_products cột mớirating_score numeric(3,2) (điểm Bayes), rating_weight_sum numeric, criteria_scores jsonb ({khoá: {score, weight_sum}}, chỉ tiêu chí đủ dữ liệu).MớiCó, DOS-Me; hàm làm mới ghi các cột này
rate.submit_community_reviewBản 2: nhận verdict, danh sách ưu nhược và số sao do API đã tính; kiểm lại các điều kiện bắt buộc (mục 4) để không ai gọi thẳng RPC mà lách được.Có sẵn, sửaCó, DOS-Me
+

Vì sao tách ưu nhược ra bảng riêng thay vì cột mảng: bước gom cần gán từng dòng vào một cụm, đếm theo tiêu chí và truy ngược "ai đã nhắc ý này". Bảng riêng làm việc đó bằng SQL thường và đánh chỉ mục được; mảng trong jsonb thì phải bung ra mỗi lần.

+ +

4. Luồng viết review

+

4.1 Form cho người dùng Rate

+
    +
  1. Chấm sao từng tiêu chí của ngành hàng, theo nửa sao. Điểm tổng tính sẵn hiện ngay bên cạnh. Được bỏ qua tối đa 2 tiêu chí, trừ "Đáng tiền".
    2. +
  2. Câu kết luận (bắt buộc, 20 đến 300 ký tự): "Ai nên mua, ai không nên". Đây là đoạn mở đầu kiểu RTINGS.
    3. +
  3. Ưu điểm và nhược điểm chung (bắt buộc): mỗi bên ít nhất 1, nhiều nhất 5 dòng, mỗi dòng 5 đến 150 ký tự. Áp dụng cả cho review chuyên gia do Rate đăng (reviewer_type = 'expert').
    4. +
  4. Ưu nhược theo tiêu chí (không bắt buộc): bấm vào một tiêu chí đã chấm để thêm 1 đến 3 dòng. Dòng ưu nhược chung mà người viết kéo vào một tiêu chí cũng tính.
    5. +
  5. Nội dung dài và ảnh (không bắt buộc, như hiện nay).
    6. +
+

4.2 Kiểm tra (ở cả API và RPC, không chỉ ở trình duyệt)

+ +

4.3 Review lấy từ nguồn khác

+ + +

5. Gom ưu nhược thành ưu nhược của sản phẩm

+

5.1 Code làm trước

+
    +
  1. Chuẩn hoá chữ: chữ thường, bỏ từ đệm ("khá", "rất", "hơi"), giữ dấu khi so hai dòng (bỏ dấu thì "sạc" và "sắc" thành một) và giữ từ phủ định ("không", "chưa", "chẳng"). Bản bỏ dấu chỉ dùng để dò từ khoá ở bước 2.
    2. +
  2. Gán tiêu chí: dòng đã gắn tiêu chí thì giữ; dòng chung thì dò từ khoá theo ngành hàng (pin, sạc, mAh cho Pin; màn, sáng, chói cho Màn hình...). Bộ từ khoá dùng lại phần trích khía cạnh đã có trong analyzer. Không khớp thì vào nhóm "Chung".
    3. +
  3. Gom cụm: hai dòng cùng tiêu chí, cùng loại, giống nhau từ 60% số từ trở lên thì vào một cụm. Đơn giản, chạy được trong SQL hoặc Node, không tốn tiền AI.
    4. +
  4. Đếm: mỗi cụm cộng trọng số tin cậy của người nhắc (mỗi người tính một lần). Review bị cổng chặn (trọng số 0) không được đếm. Dòng từ chuyên gia đánh dấu riêng.
    5. +
  5. Lọc để hiện: ưu điểm cần ít nhất 2 người khác nhau và tổng trọng số từ 1,5 trở lên, hoặc 1 chuyên gia; nhược điểm cũng vậy. Ngưỡng trọng số chặn kiểu dùng vài tài khoản mới (trọng số thấp) để dựng một ý; ngưỡng người chặn một người ghét sản phẩm tự tạo ra nhược điểm của cả sản phẩm. Mỗi tiêu chí hiện tối đa 3 ưu, 3 nhược; phần tổng của sản phẩm hiện tối đa 5 mỗi bên.
    6. +
  6. Luôn giữ nhược điểm: nếu có nhược điểm đạt ngưỡng thì phần tổng phải hiện ít nhất 1, kể cả khi ưu điểm áp đảo. Trang toàn ưu điểm là dấu hiệu seeding, và người mua cần thấy mặt yếu.
    7. +
+

5.2 AI làm phần còn lại

+ +

5.3 Độ mới

+ + +

6. Điểm giá trị review

+

6.1 Thành phần (thang 100)

+
+ + + + + + +
Thành phầnTối đaCách tính
Đầy đủ35Chấm đủ tiêu chí 10; có câu kết luận 5; có ưu và nhược chung 10; có ưu nhược theo ít nhất 2 tiêu chí 5; có ảnh thật 5.
Nội dung cụ thể20Theo trục C của mô hình tin cậy (hời hợt, ngắn nhưng cụ thể, chi tiết, chuyên sâu). Độ dài có trần: viết dài thêm sau mức đủ không được thêm điểm.
Đã mua15Có xác nhận đã mua (sàn, hoặc sau này hoá đơn). Chưa xác nhận: 0.
Vote hữu ích20Từ cận dưới Wilson của vote hữu ích (đang dùng để sắp review), nên vài vote đầu không làm điểm nhảy vọt.
Uy tín người viết10Trục D của mô hình tin cậy: tuổi tài khoản, lịch sử review, uy tín theo ngành hàng.
+

Review bị cổng chặn (giả, chép, viết cho có để lấy xu...) có điểm giá trị bằng 0, dù đầy đủ đến đâu. Review lấy từ sàn cũng có điểm này (thường thấp vì thiếu ưu nhược), nên một thang dùng chung cho mọi review.

+ +

6.2 Ảnh hưởng tới điểm sản phẩm

+

JOY muốn review đầy đủ "cao hơn một tí". Chỉ phần "Đầy đủ" ở 6.1 chạm vào trọng số, qua một hệ số nhân:

+
hệ_số_đầy_đủ = 1 + 0,25 × đầy_đủ / 35          từ ×1,00 (không có gì) đến ×1,25 (đủ hết)
+hôm nay:  w = helpfulness_weight × hệ_số_đầy_đủ,  trần 3 như cũ
+ + +

6.3 Dùng điểm giá trị ở đâu

+ + +

6.4 Rủi ro lạm dụng và cách chặn

+
+ + + + + + + + +
Rủi roChặn bằng
Điền cho đủ ô để lấy điểm ("Ưu: tốt. Nhược: không")Kiểm ở 4.2; phần "Nội dung cụ thể" chấm theo chi tiết, không theo số ô; phần "Đầy đủ" chỉ cộng khi trục C không phải hời hợt.
Viết dài, đệm chữĐộ dài có trần; chữ đệm và lặp vào nhóm "viết cho có", cổng chặn.
Chép một bộ ưu nhược cho nhiều sản phẩmSo gần giống giữa các review của cùng người và giữa các tài khoản (trục A, loại "chép từ nơi khác").
Nhóm vote cho nhauĐiều kiện vote đã có (tuổi tài khoản, xác minh, giới hạn mỗi giờ); trọng số người vote ở mục 9 của mô hình tin cậy; Wilson thay vì đếm thô.
Săn điểm thưởng hàng loạtĐiểm thưởng chỉ trao sau khi review qua bước phân tích và một thời gian giữ (ví dụ 7 ngày); điểm giảm dần theo số review trong ngày; mỗi người một review mỗi sản phẩm (đã có).
Bỏ qua 2 tiêu chí yếu nhất để số sao tổng của review cao hơnKhông chặn được hoàn toàn. Giới hạn 2 tiêu chí, không được bỏ "Đáng tiền"; điểm tiêu chí của sản phẩm không bị ảnh hưởng vì chỉ đọc tiêu chí đã chấm; phần "Đầy đủ" mất 10 điểm khi bỏ qua tiêu chí.
Người bán tự viết hoặc thuê viếtTrục B (xung đột lợi ích, tài trợ không công bố) đã có trong mô hình tin cậy.
+ +

7. Phác thảo giao diện (bố cục kiểu RTINGS)

+

7.1 Khối đánh giá trên trang sản phẩm

+
+
4.6★★★★★trên 5 · 128 review đã kiểm · Độ tin cậy cao
+
Chuyên gia: 4.4 (2 bài) · cách tính điểm
+

Kết luận: Máy mạnh, camera tốt cả ngày lẫn đêm, pin đủ một ngày dùng nhiều. Hợp người chụp ảnh và chơi game. Không hợp người cần sạc rất nhanh. Tóm tắt từ 128 review, cập nhật 31/10/2026

+
Điểm theo tiêu chí, từ 23 review trên Rate · cách tính điểm
+
Hiệu năng 20%
4.7
+
Camera 20%
4.5
+
Pin và sạc 20%
4.0
+
Màn hình 15%
4.6
+
Thiết kế và độ bền 10%
Chưa đủ
+
Đáng tiền 15%
3.8
+
+
Ưu điểm
    +
  • Chơi game nặng mượt, ít nóng · 41 người
    • +
  • Ảnh đêm rõ, ít nhiễu · 33 người
    • +
  • Màn hình sáng, dễ nhìn ngoài nắng · 27 người
    • +
+
Nhược điểm
    +
  • Sạc chậm so với máy cùng giá · 22 người
    • +
  • Giá cao, ít khuyến mãi · 15 người
    • +
+
+
Bấm vào một tiêu chí để xem ưu nhược riêng của tiêu chí đó.
+
+ +

7.2 Một thẻ review

+
+
+
Minh T. Đã muaXuất sắc· dùng 4 tháng · 12/10/2026
+
★★★★☆ 4.3 (tính từ 6 tiêu chí)
+

"Hợp người chơi game và chụp đêm; ai cần sạc nhanh nên cân nhắc."

+
+
Ưu điểm
  • Genshin max setting giữ 55 đến 60 fps
  • Chụp đêm không cần chân máy
+
Nhược điểm
  • Sạc đầy mất gần 90 phút
  • Hộp không kèm củ sạc
+
+
+ Hiệu năng ★ 5.0Camera ★ 4.5Pin và sạc ★ 3.5Màn hình ★ 4.5Thiết kế ★ 4.0Đáng tiền ★ 4.0 +
+
▸ Pin và sạc: + dùng 1 ngày rưỡi · − sạc chậm
+
👍 Hữu ích (24)👎 (1)Báo cáo
+
+
+
Người mua trên Shopee Đã muaCơ bản· nguồn: Shopee
+
★★★★★ 5.0
+

Máy đẹp, giao nhanh, dùng mượt.

+
Review từ sàn: không có ưu nhược theo tiêu chí.
+
+
+ +

8. Kế hoạch theo giai đoạn

+
+ + + + + + + + + +
Giai đoạnViệcCỡCần database?
P0Sửa #1143 trên web: bỏ điểm tiêu chí suy ra, trả null, "Chưa đủ dữ liệu", bỏ chúng khỏi điểm ghép bảng xếp hạng, so kè 1v1 không tính tiêu chí trống, ẩn tiêu chí không thuộc ngành hàng, test và OpenAPI. Merge PR #1478.SKhông
P1Danh sách tiêu chí theo ngành hàng trong shared-data (khoá, nhãn, trọng số, phiên bản) và bảng chuyển 5 khoá cũ. Web đọc danh sách này thay cho 5 khoá cố định.MKhông
P2Migration DOS-Me: cột mới trên reviews và master_products, bảng review_points, product_points; hàm làm mới ghi điểm Bayes và điểm tiêu chí. Core soạn SQL đề xuất kèm file kiểm tra và hoàn tác; JOY chạy.LCó, JOY áp dụng
P3Form review bản 2 và RPC submit_community_review bản 2: sao theo tiêu chí, kết luận, ưu nhược bắt buộc, kiểm tra ở 4.2.MSau P2
P4Một con số điểm mọi nơi (#1470): mọi trang và API đọc rating_score.SSau P2
P5Gom ưu nhược: code (5.1) rồi AI (5.2), chạy trong importer theo đợt, ghi product_points; khối 7.1 trên trang sản phẩm.M đến LSau P2
P6Điểm giá trị review: tính, lưu, sắp review, nhãn bậc, hệ số đầy đủ trên trọng số đang lưu (6.2). Áp dụng mô hình sáu trục là việc riêng, không nằm trong P6.MSau P2
SauĐiểm thưởng cho người viết (cần hệ thống điểm, thuộc DOS-Me); nhập review chuyên gia bên ngoài; AI trích ưu nhược từ review sàn.LCó
+

P0 và P1 bắt đầu được ngay sau khi JOY duyệt. P3 đến P6 chờ P2.

+ +

9. Các quyết định cần JOY

+ +
D1. Danh sách tiêu chí và trọng số ở 2.1. Duyệt bản nháp, hay sửa trọng số trước? +
Đề xuất: duyệt bản nháp làm phiên bản 1; Core chỉnh sau khi có khoảng 200 review Rate có chấm tiêu chí.
+ +
D2. Điểm tổng của sản phẩm tính thế nào. (a) Bayes trên số sao tổng của mọi review, trong đó review Rate có số sao tính từ tiêu chí theo trọng số; (b) tính thẳng từ điểm các tiêu chí của sản phẩm. +
Đề xuất: (a). (b) bỏ mất review từ sàn, và sản phẩm chưa có review Rate sẽ không có điểm.
+ +
D3. Một con số điểm cho mọi trang (#1470). Điểm Bayes lưu trên master_products (phương án 2 của PR #1478), điểm chuyên gia hiện riêng có nhãn, điểm ghép chỉ dùng để phá hoà. +
Đề xuất: duyệt, và merge PR #1478 ngay.
+ +
D4. Sửa #1143 bây giờ (P0). Bỏ điểm tiêu chí suy ra; trang và API hiện "Chưa đủ dữ liệu". Một số chip "#1" và bảng xếp hạng theo tiêu chí sẽ vắng đi vì đa số sản phẩm chưa có dữ liệu tiêu chí. +
Đề xuất: làm ngay. Số ít mà thật tốt hơn số nhiều mà bịa.
+ +
D5. Mức bắt buộc của form. Bắt buộc câu kết luận, ít nhất 1 ưu và 1 nhược chung, chấm đủ tiêu chí (bỏ qua tối đa 2, trừ "Đáng tiền"); ưu nhược theo tiêu chí không bắt buộc. +
Đề xuất: duyệt như trên. Điểm này khác ý ban đầu của JOY (ưu nhược cho cả từng tiêu chí): bắt buộc ưu nhược cho từng tiêu chí làm form quá dài, người dùng bỏ giữa chừng. Ưu nhược theo tiêu chí vẫn có, được cộng điểm giá trị, và dòng chung được tự gán tiêu chí ở bước gom.
+ +
D6. Điểm giá trị review ảnh hưởng điểm sản phẩm bao nhiêu. (a) Chỉ dùng để sắp review và gắn nhãn; (b) nâng nhẹ trọng số bằng hệ số đầy đủ, từ ×1,00 đến ×1,25 (6.2); (c) nhân cả điểm giá trị 0 đến 100 vào trọng số. +
Đề xuất: (b). Đúng ý "cao hơn một tí", không tính vote hai lần, không mở đường cho người tối ưu con số để kéo điểm sản phẩm.
+ +
D7. Hiện điểm giá trị ra sao. Con số công khai, hay chỉ bậc công khai và con số cho riêng người viết. +
Đề xuất: bậc công khai, con số chỉ người viết thấy.
+ +
D8. Điểm thưởng cho người viết. Rate chưa có hệ thống điểm. Điểm thưởng nằm ở Rate hay ở DOS-Me (tài khoản chung của hệ sinh thái), và quy đổi ra gì. +
Đề xuất: tách thành một quyết định riêng sau P6; khi làm thì đặt ở DOS-Me, trao sau 7 ngày giữ và sau bước phân tích. Điểm giá trị review là đầu vào sẵn sàng cho việc đó.
+ +
D9. Ngưỡng hiển thị. Một ưu hoặc nhược của sản phẩm: ít nhất 2 người khác nhau và tổng trọng số từ 1,5, hoặc 1 chuyên gia; luôn giữ ít nhất 1 nhược điểm nếu có. Một điểm tiêu chí: ít nhất 3 người viết; xếp hạng theo tiêu chí: ít nhất 5. +
Đề xuất: duyệt.
+ +
D10. Migration DOS-Me cho P2. Core soạn SQL đề xuất (cột, bảng, hàm làm mới, file kiểm tra, file hoàn tác) để JOY xem và áp dụng qua DOS-Me. +
Đề xuất: duyệt để Core soạn; không có gì được áp dụng khi chưa có lệnh của JOY.
+ +

10. Không nằm trong đề xuất này

+ +
+ +