IQRDC 2026 — Proses 1–3 (Submission → Sheet → Penilaian) | MC-ATERA Premium
IQRDC 2026 • Proses 1–3 (Rujukan & Pengajaran)
MC-ATERA Premium Format
Proses 1–3 IQRDC 2026
Submit Form → Masuk Google Sheet → Penilaian & Markah (Portal Penilai)

Halaman ini menerangkan 3 proses teras sistem IQRDC: (1) peserta submit borang HTML, (2) data disimpan ke Google Sheets melalui Apps Script Web App, dan (3) panel penilai memberi markah menggunakan Evaluator Portal (HTML Premium). Sesuai untuk rujukan pelaksanaan dan bahan pengajaran.

Default (dipersetujui): Total markah 1002 penilai bagi setiap submission • Komponen proposal sahaja dahulu.

Dokumentasi Proses 1–3 (End-to-End)

MC-ATERA Premium

Gambaran Keseluruhan (Flow)

Matlamat: Peserta submit sekali di front-end, Prof/Panel menilai di back-end yang tersusun dan boleh diaudit.

① HTML Form (Peserta) — Webador Ready
Peserta isi semua medan + word limit validation → Submit.
② Apps Script Web App (API Endpoint)
Terima JSON (POST) → simpan ke Google Sheets (Submissions).
③ Evaluator Portal (Panel) — HTML Premium
Panel lihat submission → isi rubric → auto total → simpan ke Sheets (Evaluations).
Kunci kejayaan: Asingkan “data mentah” (Submissions) dan “markah” (Evaluations) supaya sistem kemas, selamat, dan mudah disemak.
1 Proses 1 — Peserta Submit Borang HTML
Front-End

Apa berlaku: Peserta melengkapkan borang proposal (tanpa upload) dan sistem akan memastikan min–max word limit, medan wajib, dan deklarasi dipenuhi sebelum membenarkan submit.

  • Validasi: word limits + required fields + checkbox declaration.
  • Format data: dihantar sebagai JSON (payload) ke endpoint Apps Script.
  • Best practice: guna email sama seperti pendaftaran/pembayaran untuk matching.
Contoh Payload (JSON) yang dihantar
{
  "action": "submitProposal",
  "data": {
    "FullName": "Nama Peserta",
    "Email": "nama@email.com",
    "ParticipantID": "IQRDC-2026-000123",
    "Category": "Student Researcher",
    "ProjectTitle": "Tajuk Kajian",
    "ProblemStatement": "...",
    "PurposeOfStudy": "...",
    "MainResearchQuestion": "...",
    "SubResearchQuestions": "...",
    "Theory": "...",
    "ResearchDesignAndJustification": "...",
    "SamplingAndParticipants": "...",
    "DataCollection": "...",
    "DataAnalysis": "...",
    "Ethics": "...",
    "Trustworthiness": "...",
    "Impact": "...",
    "ExecutiveSummary": "...",
    "SubmittedAt": "2026-01-15T00:00:00.000Z",
    "FormVersion": "IQRDC-2026-Structured-v1"
  }
}

Nota: Dalam Apps Script, jika SubmissionID tidak dihantar, sistem akan auto-generate.

Snippet “koneksi” dalam borang HTML peserta
// 1) Set endpoint Apps Script
const ENDPOINT_URL = "PASTE_APPS_SCRIPT_WEBAPP_URL_HERE";

// 2) Bila submit, bungkus payload ikut format API
const payload = collectFormData();

await fetch(ENDPOINT_URL, {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ action:"submitProposal", data: payload })
});
2 Proses 2 — Data Masuk Google Sheets (Database)
Back-End Storage

Apa berlaku: Apps Script menerima JSON dan menyimpan data ke tab Submissions. Ini menjadi “single source of truth” untuk semua proposal.

  • Tab Submissions: menyimpan semua jawapan peserta (mentah).
  • SubmissionID: ID unik untuk rujukan & linking penilaian.
  • Status: NEW / IN-REVIEW / SCORED (boleh dikembangkan).
Header Tab “Submissions” (disyorkan)
SubmissionID	SubmittedAt	FormVersion	FullName	Email	ParticipantID	Category	ProjectTitle	ProblemStatement	PurposeOfStudy	MainResearchQuestion	SubResearchQuestions	Theory	ResearchDesignAndJustification	SamplingAndParticipants	DataCollection	DataAnalysis	Ethics	Trustworthiness	Impact	ExecutiveSummary	Status

Tip: Pastikan header ini tepat (Apps Script append ikut header). Ini elak data “lari kolum”.

Apps Script Web App — fungsi asas yang perlu ada
✅ doPost(action="submitProposal")  → appendRow ke tab Submissions
✅ doGet(action="listSubmissions")  → list untuk portal penilai
✅ doGet(action="getSubmission")    → tarik 1 submission penuh (viewer)
✅ doPost(action="saveEvaluation")  → simpan markah panel ke tab Evaluations
Kenapa Google Sheet? Mudah audit, mudah filter, mudah eksport, dan sesuai untuk operasi sekretariat. Untuk scale besar, boleh migrasi ke DB lain kemudian.
3 Proses 3 — Penilaian & Markah (Evaluator Portal)
Scoring

Apa berlaku: Panel membuka portal penilai (HTML Premium), melihat proposal secara teratur, mengisi rubric, sistem mengira jumlah markah, kemudian menyimpan markah ke tab Evaluations.

  • Rubric 100 markah: 9 kriteria (20/10/20/10/10/10/10/5/5).
  • 2 panel: setiap submission ada 2 record penilaian (EvaluatorID berbeza).
  • Recommendation: auto (Gold/Silver/Bronze/Pass/Revise) ikut ambang.
Header Tab “Evaluations” (disyorkan)
EvalID	SubmissionID	EvaluatorID	EvaluatedAt	Score_ClarityAlignment	Score_TheoryLens	Score_DesignJustification	Score_Sampling	Score_DataCollection	Score_DataAnalysis	Score_Ethics	Score_Trustworthiness	Score_Impact	TotalScore	Comments	Recommendation
Contoh rekod penilaian (1 panel)
{
  "action":"saveEvaluation",
  "evaluatorID":"EVAL01",
  "pin":"1234",
  "data":{
    "SubmissionID":"IQRDC-2026-20260115-101010-1234",
    "Score_ClarityAlignment":18,
    "Score_TheoryLens":8,
    "Score_DesignJustification":17,
    "Score_Sampling":8,
    "Score_DataCollection":9,
    "Score_DataAnalysis":8,
    "Score_Ethics":9,
    "Score_Trustworthiness":4,
    "Score_Impact":5,
    "TotalScore":88,
    "Comments":"Kuat dari segi alignment & justifikasi; cadang perincikan prosedur temubual.",
    "Recommendation":"Gold"
  }
}
Best practice penilaian: Jangan benarkan panel edit tab Submissions. Panel hanya submit markah melalui portal → masuk Evaluations. Ini kurangkan kesilapan & kekalkan integriti data.

Nota Pengajaran (Untuk kelas / latihan panel)

Gunakan halaman ini untuk menerangkan konsep: Front-end (form), API (Apps Script), Data store (Google Sheets), dan Back-end UI (Evaluator Portal).

Outcome 1: Pelajar/Panel faham kenapa data mentah & markah perlu diasingkan.
Outcome 2: Pelajar boleh jelaskan peranan endpoint (POST/GET) dalam sistem.
Outcome 3: Panel boleh menilai secara standard menggunakan rubric 100 markah.
IQRDC 2026 — Proses 4: Verifier Decision (Selepas 2 Assessor) | MC-ATERA Premium
IQRDC 2026 • Proses 4: Verifier Decision
Selepas 2 Assessor
Verifier Menetapkan Keputusan Rasmi
Gabung 2 Markah Assessor → Semak Variance → Tetapkan Keputusan (Final)

Dalam Proses 4, Prof sebagai Verifier akan melihat 2 penilaian (Assessors), mengira purata, menyemak perbezaan (variance), dan menetapkan keputusan rasmi tanpa mengubah rekod markah asal assessor. Keputusan ini akan direkodkan sebagai Final Decision.

Cadangan dasar: Jika beza markah assessor melebihi 10 mata, status jadi REVIEW REQUIRED (Verifier boleh minta semakan/3rd assessor atau buat keputusan dengan justifikasi).

Proses 4 (Rujukan Lengkap)

Verifier Workflow

Kaedah Terbaik (Governance & Integriti)

Prinsip utama: Markah assessor adalah rekod asal (tidak diubah). Verifier hanya membuat rekod keputusan akhir berdasarkan bukti.

  • Step 1: Pastikan sudah ada 2 rekod penilaian dalam tab Evaluations.
  • Step 2: Sistem kira AverageScore dan Variance.
  • Step 3: Jika variance tinggi → REVIEW REQUIRED (minta semakan / 3rd assessor).
  • Step 4: Verifier pilih Final Decision + tulis justifikasi ringkas.
  • Step 5: Keputusan disimpan dalam tab FinalDecisions (atau tab Summary).

Struktur Data Tambahan: Final Decision (Disyorkan)

Tambah satu tab baru dalam Google Sheet bernama FinalDecisions. Tab ini menyimpan keputusan rasmi (Verifier) selepas 2 assessor.

Tab: FinalDecisions (Header)
Simpan keputusan akhir + bukti ringkas + audit trail.
New Tab
DecisionID	SubmissionID	VerifierID	VerifiedAt	Assessor1_ID	Assessor1_Total	Assessor2_ID	Assessor2_Total	AverageScore	Variance	FinalDecision	FinalAward	Status	VerifierNotes
Definisi medan (ringkas)
Untuk latihan panel & dokumentasi SOP.
SOP
  • AverageScore = (Total A1 + Total A2) / 2
  • Variance = |Total A1 − Total A2|
  • Status = OK / REVIEW REQUIRED / FINALIZED
  • FinalDecision contoh: ACCEPT / REVISE / REJECT
  • FinalAward contoh: Gold / Silver / Bronze / Pass / —
Kenapa tab FinalDecisions penting? Ia membezakan “markah penilai” (Evaluations) dan “keputusan rasmi” (FinalDecisions). Ini standard governance pertandingan.

Portal Verifier (Demo untuk Rujukan & Pengajaran)

Portal ini menunjukkan bagaimana Verifier membuat keputusan berdasarkan 2 markah assessor, termasuk pengiraan Average dan Variance, serta pemilihan keputusan rasmi. (Versi demo: data contoh; boleh sambung ke API kemudian.)

Maklumat Submission (Contoh)
Dalam sistem sebenar, ini diambil dari Submissions + Evaluations.
Viewer
Submission ID
Category
Assessor 1 (ID)
Assessor 1 (Total)
Assessor 2 (ID)
Assessor 2 (Total)
Average Score
Variance (|A1-A2|)
Status

Polisi contoh: Variance > 10 → REVIEW REQUIRED.

Keputusan Rasmi (Verifier)
Verifier membuat keputusan akhir + justifikasi ringkas (audit).
Final Decision
Verifier ID
Final Decision
Final Award (Medal/Tier)
Status Rekod
Verifier Notes (Justifikasi ringkas)