پروپوزال کنفرانس تست؛ از CFP تا Submission

پروپوزال کنفرانس «نسخه کوچک سخنرانی» یا متن تبلیغاتی برای فروش ایده نیست. یک submission محدود به فرم، deadline و قواعد یک CFP مشخص است که باید به دو گروه پاسخ دهد: داور می‌خواهد fit، کیفیت، امکان اجرا و ریسک را بسنجد؛ مخاطب آینده می‌خواهد بداند آیا این Session برای نیاز و پیش‌نیاز او مناسب است. قلاب جذاب بدون evidence، outcome یا انطباق با فرم می‌تواند هر دو را گمراه کند.

این راهنما یک Conference Proposal Submission Record می‌سازد: CFP Snapshot → Eligibility/Obligation/Review Model → Audience/Problem/Claim/Evidence → Outcome/Format/Outline/Feasibility → Speaker/Permission/Disclosure → Preflight/Submit/Receipt → Decision/Feedback/Revision/Withdrawal. هدف، تضمین پذیرش یا «حداکثرکردن شانس» با ترفند نیست؛ هدف، ارسال دقیق، صادقانه، قابل‌ردیابی و قابل‌تحویل است.

خلاصه عملی: ده Gate پیش از Submit

• CFP identity: رویداد، edition/year، URL، timezone و snapshot درست‌اند.
• Eligibility: submitter، speaker، تعداد submission و format مجازند.
• Obligations: هزینه، سفر، حضور، training، agreement و deadline پذیرفتنی‌اند.
• Review: معیار، blind/non-blind، conflict و مراحل selection فهمیده شده‌اند.
• Fit: Track، audience، problem و why-here/why-now روشن‌اند.
• Substance: Claim، evidence، limitations و status کار صادقانه‌اند.
• Outcome: مخاطب بعد از Session چه کار قابل مشاهده‌ای می‌تواند انجام دهد؟
• Feasibility: format، time، interaction، demo و accessibility عملی‌اند.
• Integrity: authorship، contribution، NDA/IP/privacy، commercial و AI disclosure درست‌اند.
• Submission: همه fieldها، limitها، anonymity، receipt و نسخه نهایی تأیید شده‌اند.

CFP چیست و چرا تنها منبع اصلی قواعد است؟

Call for Proposals/Papers/Content سند فراخوان همان edition رویداد است. این سند می‌تواند Track، format، audience، deadline، timezone، fieldها، character/word limit، review criteria، anonymity، disclosure، هزینه و تعهدهای پس از پذیرش را تعیین کند. راهنمای عمومی—از جمله همین مقاله—بر CFP جاری مقدم نیست. صفحه سال قبل، پست شبکه اجتماعی یا حافظه سخنران قبلی نیز جای نسخه جاری را نمی‌گیرد.

اول یک CFP Snapshot غیرقابل‌ابهام بسازید

صفحات رویداد ممکن است پس از ارسال تغییر کنند. URL، متن و fieldهای فرم را در زمان تصمیم snapshot کنید؛ اما حق‌نشر، robots و دسترسی را رعایت کنید و نسخه عمومی غیرمجاز نسازید. screenshot تنها کافی نیست؛ متن deadline، timezone، field limit و requirement را ساختاریافته استخراج و source location را نگه دارید.

CFPID | Event/Edition/Year | Organizer | OfficialURL
SnapshotAt/Timezone/Hash | Opens/Deadline/Decision dates
Submission portal/version | Tracks | Formats | Languages
Fields/limits/visibility | Eligibility | Review/selection model
Costs/benefits/obligations | Policies | Contacts | Change log

«قالب استاندارد پروپوزال» وجود ندارد

سه فراخوان رسمی جاری تفاوت را روشن می‌کنند. CFP سال ۲۰۲۶ EDUCAUSE برای Title، Abstract، سه Takeaway، Engagement، Description، Keyword و Level field و limit جدا دارد و هزینه کامل ثبت‌نام/سفر حضوری را بر عهده presenter می‌گذارد. این صفحه در مرورگر قابل‌خواندن بود اما curl مستقیم HTTP ۴۰۳ ضدبات داد.

فراخوان ۲۰۲۶ AHEAD abstract عمومی، description، outline، learning goal و برنامه تحقق آن، inclusion description و references را می‌خواهد و review را anonymous اعلام می‌کند. راهنمای submission کنوانسیون ASHA formatهای متفاوت و learning outcome اجباری دارد و تکمیل disclosure همه authorها را شرط باقی‌ماندن کل proposal در داوری می‌داند. این مثال‌ها نسخه rules رویداد شما نیستند؛ فقط نشان می‌دهند عدد و field عمومی قابل تعمیم نیست.

تاریخ و Timezone را مثل Requirement تست کنید

«تا جمعه» بدون timezone، ساعت و calendar مبهم است. deadline را با offset/IANA zone و معادل محلی ثبت کنید؛ تغییر ساعت فصلی و تفاوت تاریخ جلالی/میلادی را کنترل کنید. submit را به دقیقه آخر موکول نکنید: account، email verification، file upload، CAPTCHA، شبکه یا payment می‌توانند مانع شوند. deadline داخلی زودتر و escalation route داشته باشید.

Eligibility را پیش از نوشتن بسنجید

• عضویت، سن، وابستگی یا منطقه جغرافیایی لازم است؟
• Submitter باید presenter یا author باشد؟
• حداکثر چند proposal و چند نقش برای هر نفر مجاز است؟
• کار قبلاً ارائه/منتشر/پذیرفته شده یا هم‌زمان جای دیگری ارسال شده می‌تواند باشد؟
• Research باید complete باشد یا work-in-progress پذیرفته می‌شود؟
• همه co-speakerها باید account، consent، bio و disclosure کامل کنند؟
• زبان، format، حضور فیزیکی/آنلاین و دسترسی فنی قابل اجراست؟
• دعوت، vendor/sponsor یا کارمند برگزارکننده قواعد جدا دارد؟

در پاسخ، بله/خیر حدسی ننویسید. Clause، source، وضعیت Confirmed/Unknown/NotApplicable و owner را ثبت کنید. اگر Portal و CFP اختلاف دارند، از contact رسمی clarification بگیرید و پاسخ را version کنید.

هزینه و تعهد پس از پذیرش بخشی از Fit است

پذیرش ممکن است بلیت رایگان، honorarium یا پوشش سفر نداشته باشد. ثبت‌نام، پرواز، اقامت، بیمه، ویزا، مالیات، دسترسی ارزی، اینترنت، مرخصی و زمان preparation را پیش از submit برآورد کنید. برای متقاضی داخل ایران، محدودیت پرداخت/ویزا/تحریم یا دسترسی portal می‌تواند جدی باشد؛ اما وضعیت را از منبع جاری رویداد و ارائه‌دهنده مربوط بررسی کنید، نه فرض عمومی. پذیرش CFP تضمین ویزا، پرداخت یا ورود نیست.

ObligationID | CFPID | Item[registration,travel,visa,training,...]
Who pays/acts | Amount/currency/tax/estimate date | Deadline
Refund/cancellation/substitution | Evidence | Dependency
Feasible/Unknown/Blocked | Owner | Contingency | Approval

Review و Selection را یکی ندانید

Reviewer ممکن است proposal را با rubric امتیاز دهد؛ committee سپس با ظرفیت slot، balance موضوع، format، audience، diversity هدف برنامه، تعارض زمان و دعوت‌ها program را نهایی کند. امتیاز خوب پذیرش را تضمین و رد شدن کیفیت پایین را اثبات نمی‌کند. تعداد رقبا، matching reviewer و portfolio selection معمولاً خارج از کنترل submitter است.

Blind Review دقیقاً چه چیزهایی را پنهان می‌کند؟

Anonymous، single-blind و double-blind تعاریف/اجرای یکسانی در همه رویدادها ندارند. مشخص کنید کدام field به reviewer می‌رسد، bio چه زمانی دیده می‌شود و self-citation چگونه باید نوشته شود. نام/شرکت ممکن است از عنوان پروژه، client، repository، URL، screenshot، file metadata، DOI، سبک self-reference یا دستاورد یکتا قابل حدس باشد. دقیقاً قواعد CFP را اجرا کنید؛ ناشناس‌سازی اضافه هم ممکن است clarity یا citation را خراب کند.

ReviewModelID | Stage | Reviewer/Committee role | Visible fields
Identity hidden from whom | Scoring criteria/scale/weight
Conflict rules | Reviewer assignment | Comments/appeal
Program-balance stage | Decision authority | Unknowns

Rubric را به Trace Matrix تبدیل کنید

کلمات «تازگی، کاربردی، الهام‌بخش» را حدس نزنید. criterion رسمی را به سؤال قابل پاسخ تبدیل کنید و برای هر کدام field/evidence مشخص کنید. اگر Rubric منتشر نشده، چیزی را به reviewer نسبت ندهید؛ از CFP و فرم، requirementهای مشاهده‌پذیر استخراج و Unknown را حفظ کنید.

CriterionID | Exact criterion/source | Interpretation (labelled)
ProposalField/Section | Evidence/Statement | Limit/format
Reviewer question | Risk/Unknown | Reviewer feedback later

Track را با Fit انتخاب کنید، نه با شلوغی کمتر

تعریف Track، audience و examples را بخوانید. proposal چندرشته‌ای می‌تواند fit چند Track داشته باشد؛ اگر فقط یکی مجاز است، جایی را انتخاب کنید که problem، outcome و reviewer expertise بیشترین هم‌راستایی دارند. «Help me decide» یا contact رسمی را اگر وجود دارد استفاده کنید. Gaming دسته‌بندی می‌تواند reviewer نامتناسب بسازد.

Archive کنفرانس Signal است، نه قانون منع تکرار

برنامه سال‌های قبل، recording و abstractها کمک می‌کنند vocabulary، عمق، format و gapهای احتمالی را ببینید. نبود موضوع، نیاز قطعی را ثابت نمی‌کند؛ وجود آن نیز proposal شما را بی‌ارزش نمی‌کند. تفاوت را دقیق کنید: context، evidence، failure، population، version، method، counterexample یا outcome. ادعای «اولین/تنها» نیازمند دامنه جست‌وجوی قابل دفاع است و معمولاً ضروری نیست.

Idea Brief قبل از Abstract

پیش از بازی با عنوان، یک صفحه بنویسید: چه کسی با چه مسئله‌ای در چه contextی روبه‌روست؟ چه ادعای محدود و evidenceای دارید؟ Session چه چیزی را تغییر می‌دهد؟ چه چیزی خارج است؟ چرا این format و رویداد؟ اگر Brief منسجم نیست، polish abstract مشکل را پنهان می‌کند.

IdeaID/Version | Audience/Context | Problem/Consequence
Current options/gap | Main claim | Evidence/status
Outcome | Why this event/track/now | Format rationale
Limitations/NotClaimed | Permission/feasibility risks

Problem Statement را با «درد بازار» نمایشی نسازید

«همه تیم‌های QA از flaky test رنج می‌برند» population و evidence ندارد. Problem را برای audience و context مشخص بنویسید، current workaround و consequence را محدود کنید و uncertainty را نگه دارید. exaggeration شاید attention بگیرد اما توقع غلط و reviewer concern می‌سازد.

Claim و Status کار باید صریح باشد

Completed study، operational case، controlled experiment، experience report، tutorial، proposal، opinion و work-in-progress evidence یکسان ندارند. نگویید «نتایج نشان می‌دهد» اگر analysis کامل نشده است. planned result را با actual result مخلوط نکنید و اگر داده ممکن است تا روز رویداد تغییر کند، condition و fallback را بنویسید.

SubmissionClaimID | Exact claim | Work type/status/cutoff date
Context/Population/Version | Method/Evidence | Result
Uncertainty/Alternative | Limitations | NotClaimed
Expected change before event | Verification/Reviewer note

Case Study واقعی را برای acceptance قربانی نکنید

نوشتن نام مستعار client، حذف logo یا بیان «یک فین‌تک بزرگ» Permission ایجاد نمی‌کند و ممکن است reidentification را آسان کند. قرارداد/NDA، IP، privacy، security، vulnerability/incident، employer/client approval، داده و حق publication را بررسی کنید. وقتی حق روشن نیست، case مستقل fictional بسازید و label کنید. برای جریان کامل از Artifact تا Evidence قابل انتشار استفاده کنید.

عنوان باید promise دقیق بدهد

Title را مطابق character limit و style CFP بنویسید. Subject، tension/outcome و boundary را تا حد لازم نشان دهید. keyword stuffing، clickbait، «از صفر تا صد»، «راهنمای نهایی»، «تضمینی»، «بی‌نظیر» و نام tool/product—وقتی ممنوع یا فرعی است—حذف شوند. عنوان باید با public abstract، outcome و محتوای واقعی align بماند.

Abstract عمومی با Reviewer Notes یکی نیست

بعضی فرم‌ها abstract را بعد از پذیرش در برنامه عمومی منتشر می‌کنند، در حالی که detailed description فقط برای review است. public text باید برای attendee قابل فهم، دقیق و بدون اطلاعات محرمانه/داوری باشد؛ reviewer text می‌تواند روش، outline، evidence و feasibility بیشتری بدهد. هر field را بر اساس stated audience آن بنویسید و فرض نکنید private می‌ماند مگر policy بگوید.

قالب Abstract را از field استخراج کنید

• Context: audience و situation محدود؛
• Problem/Question: مسئله بدون اغراق؛
• Approach: نوع Session و روش/مدل؛
• Evidence/Status: آنچه واقعاً انجام شده؛
• Outcome: توان قابل مشاهده مخاطب؛
• Boundary: prerequisite، limitation یا چیزی که Session نیست.

این ترتیب template اجباری نیست. اگر field فقط ۵۰۰ character دارد، اولویت را از CFP بگیرید. «فروش» جای clarity را نگیرد و همه جزئیات را در یک جمله فشرده نکنید. نسخه character-count شده را با همان Unicode portal بررسی کنید.

Learning Outcome باید observable و deliverable باشد

«آشنایی»، «درک عمیق» و «الهام» به‌تنهایی مشاهده‌پذیر نیستند. بنویسید مخاطب با چه input و constraint می‌تواند چه actionی انجام دهد: تفکیک، طراحی، تشخیص، مقایسه یا critique. Outcome به زمان/format، prerequisite، outline و interaction وصل شود. وعده‌ای که فقط با workshop سه‌ساعته ممکن است در talk بیست‌دقیقه‌ای ندهید.

OutcomeID | Audience/prerequisite | Observable action
Object/input/context | Success boundary | Session segment/activity
Evidence of learning (if required) | Accessibility alternative
Feasible in format/time? | Limitation

Takeaway فهرست مطالب نیست

«معرفی K6، Grafana و CI» فقط topic است. Takeaway باید value قابل انتقال را بگوید: «یک baseline را با workload/metric/version طوری ثبت کند که دو run قابل مقایسه شوند.» تعداد را همان CFP تعیین می‌کند. Takeawayها نباید نسخه تکراری abstract یا promise فراتر از evidence باشند.

Outline باید امکان تحویل وعده را نشان دهد

برای هر segment purpose، Claim، activity/artifact و time بنویسید. Q&A، setup، interaction، accessibility delay و buffer را لحاظ کنید. جزئیات tool setup نباید outcome اصلی را ببلعد. اگر CFP فقط چند bullet می‌خواهد، نسخه کوتاه همان Run of Show را بدهید، نه یک agenda آرزویی.

Segment	هدف	Evidence/Activity	Time
Context	تعریف history و Unknown	دو trace ساختگی	۳ دقیقه
Model	تفکیک قبل/بعد commit	state diagram	۶ دقیقه
Exercise	اعمال تمایز	poll اختیاری + پاسخ متنی	۵ دقیقه
Counterexample	مرز روش	missing evidence	۳ دقیقه
Transfer	اقدام بعدی	checklist + limitation	۳ دقیقه

Format را براساس Outcome انتخاب کنید

Format	Evidence لازم در proposal	ریسک
Lightning	یک Claim/Takeaway بسیار محدود	overpromise و context ناکافی
Talk	narrative/outline و انتقال روشن	interaction یا depth نمایشی
Workshop	activity، prerequisite، setup، ratio، support و output	بار setup/accessibility/assistants
Panel	question architecture، perspective و moderation	اسم‌های بزرگ بدون synthesis
Poster/Demo	visual/demo access و interaction loop	وابستگی فنی و دسترس‌پذیری

Workshop Proposal یک Talk کش‌آمده نیست

برای workshop باید task، instruction، materials، prerequisite، setup time، participant device/account، network، dataset، group size، facilitator ratio، accessible alternative، completion evidence، reset/cleanup و contingency را توضیح دهید. ابزار پولی یا محدود جغرافیایی می‌تواند exclusion بسازد. participant نباید برای تمرین، data/credential واقعی وارد کند.

Live Demo را فقط اگر برای Claim لازم است پیشنهاد دهید

Demo سبز novelty یا learning را ثابت نمی‌کند. dependency، network، account، data، زمان reset و fallback را در feasibility بسنجید. اگر static trace همان outcome را بهتر منتقل می‌کند، live بودن ارزش ذاتی ندارد. برای طراحی Runbook اجرا از ارائه فنی QA از Claim تا Q&A استفاده کنید.

Engagement را با سرگرمی اشتباه نگیرید

اگر CFP Engagement می‌خواهد، فعالیت را به Outcome وصل کنید: participant چه inputی می‌گیرد، چه actionی انجام می‌دهد، چه feedbackی می‌گیرد و راه جایگزین چیست؟ Poll، pair discussion یا Q&A به‌خودی‌خود یادگیری فعال نیست. skip، anonymity، time، privacy، mobility، speech، hearing، vision، language و remote access را لحاظ کنید.

Accessibility را داخل Proposal قابل مشاهده کنید

صفحه رسمی W3C WAI برای ارائه و رویداد دسترس‌پذیر دسترسی را مسئولیت مشترک organizer و speaker می‌داند: مواد adaptable از قبل، caption/transcript، توصیف visual، microphone و زمان پردازش. اگر field مرتبط وجود دارد، مواد/interaction/format خود را مشخص کنید؛ ادعای «کاملاً دسترس‌پذیر» یا Compliance بدون scope و evaluation ندهید.

Bio باید Topic Fit را نشان دهد، نه prestige

اگر bio به reviewer می‌رسد، فقط همان اطلاعات خواسته‌شده و مرتبط را بدهید. اگر review blind است، نام، سازمان، client، لینک و self-identifying claim را از fieldهای blind حذف کنید. سال سابقه، title و follower دلیل صحت Claim نیست. contribution، context و evidence قابل ارائه را بدون ادعای «رهبر فکری» توضیح دهید.

Co-speakerها Author decoration نیستند

هر فرد باید سهم، consent، eligibility، availability، هزینه/سفر، disclosure و مسئولیت deliverable را بداند. ترتیب نام، contact submitter، presenter جایگزین و withdrawal را توافق کنید. شخص را برای تنوع ظاهری، اعتبار یا دورزدن limit اضافه نکنید. نظر و تجربه affected group را بدون مشارکت/permission تصاحب نکنید.

ContributorID | Role[submitter,author,speaker,facilitator]
Contribution | ConsentAt | Eligibility/account/disclosure state
Availability/travel/cost | Deliverables/deadlines | Attribution
Conflict/relationship | Substitute/withdrawal plan | Contact owner

Authorship، plagiarism و AI را شفاف مدیریت کنید

متن/ایده/تصویر/کد دیگران را مطابق citation، license و policy استفاده کنید. paraphrase بدون attribution می‌تواند plagiarism باشد. درباره ابزار مولد AI، policy همان CFP/رویداد را بررسی کنید: مجازبودن، disclosure، محرمانگی input، copyright، hallucination و مسئولیت صحت. AI نویسنده مسئول یا evidence نیست؛ انسان نام‌برده باید ادعاها و submission را بازبینی و پاسخ‌گو باشد.

Commercial Interest و Conflict را پنهان نکنید

استخدام در vendor، sponsorship، مالکیت tool، consulting، referral یا research funding می‌تواند مرتبط باشد. disclosure به‌تنهایی bias را حذف نمی‌کند، اما اطلاعات لازم برای review و audience می‌دهد. محصول را وقتی برای فهم لازم است نام ببرید و alternatives/limitations را نشان دهید. قواعد non-promotional، logo و vendor session را از CFP بگیرید.

DisclosureID | Person/Organization/Topic | Relationship/Benefit
Financial/Employment/IP/Sponsorship/Funding | Relevance
Required field/audience | Wording | Mitigation/alternatives
Source policy | ReviewedAt | Status/Correction

متقاعدسازی داور باید اخلاقی بماند

Reviewer را با prestige، urgency ساختگی، social proof، ادعای انحصار یا پنهان‌کردن limitation هل ندهید. proposal باید evidence و trade-off لازم برای judgment مستقل را بدهد. راهنمای متقاعدسازی اخلاقی در QA مرز Influence با manipulation را پوشش می‌دهد.

نسخه فارسی/انگلیسی را field-by-field بسازید

ترجمه لفظی title/abstract ممکن است character limit، ambiguity و terminology رویداد را خراب کند. Language tag، glossary و spelling variant را با audience هماهنگ کنید. ی/ی، ک/ک، نیم‌فاصله، رقم فارسی/عربی/لاتین و RTL/LTR/Bidi را در portal و email receipt تست کنید. timezone و تاریخ جلالی را فقط با معادل میلادی/offset روشن به کار ببرید. راهنمای ارتباط بین‌فرهنگی QA مرز ترجمه و معنا را باز می‌کند.

Character Limit را با همان منطق Portal بسنجید

Word، character، character-with-spaces و byte یکسان نیستند. emoji، نیم‌فاصله، newline، HTML entity و Unicode normalization می‌توانند شمارش را تغییر دهند. ابتدا در فایل ساده نسخه fieldها را نگه دارید، سپس paste و counter واقعی portal را ثبت کنید. truncation خاموش یا حذف paragraph را بعد از submit بررسی کنید.

Supplemental Link همیشه امتیاز نیست

برخی CFPها attachment/link را نمی‌خواهند یا reviewer آن را نمی‌بیند. لینک می‌تواند identity را در blind review افشا، login بخواهد، expire شود یا داده محرمانه داشته باشد. فقط در field مجاز و برای purpose روشن اضافه کنید؛ access ناشناس، permission، license، immutability و snapshot را بررسی کنید. لینک عمومی GitHub خودبه‌خود evidence معتبر یا مجاز نیست.

Preflight را مستقل از نویسنده اجرا کنید

• Event/edition/track/format و deadline درست؛
• eligibility و obligations بدون Unknown بحرانی؛
• تمام fieldهای required و conditional کامل؛
• limitها در portal، نه فقط editor، معتبر؛
• title/abstract/outcome/outline هم‌راستا؛
• Claim/status/evidence/limitation صادقانه؛
• anonymity و file/link metadata مطابق policy؛
• names/order/affiliation/email/account صحیح؛
• consent/contribution/disclosure همه افراد کامل؛
• NDA/IP/privacy/security/license pass؛
• format/time/interaction/demo/accessibility قابل اجرا؛
• grammar/links/date/timezone و public visibility بازبینی؛
• هزینه/سفر/registration/training feasibility تأیید؛
• نسخه نهایی freeze، export و hash شده است.

برای کیفیت fieldهای نوشتاری، از ارتباط نوشتاری QA از Purpose تا Action استفاده کنید. Reviewer مستقل نباید فقط typo بگیرد؛ mismatch وعده، ambiguity، overclaim، rule violation و feasibility را پیدا کند.

Submission Run را ثبت کنید

قبل از کلیک نهایی preview را line-by-line بخوانید. SubmissionID، timestamp/zone، proposal version/hash، portal state، confirmation number و receipt email را ذخیره کنید. داده حساس account/session/token را در record نگذارید. اگر portal اجازه amendment دارد، deadline و رفتار version را ثبت کنید؛ edit بعدی ممکن است review را reset یا audit trail را تغییر دهد.

SubmissionID | CFPID | ProposalVersion/Hash | Submitter
Portal/AccountID (non-secret) | SubmittedAt/Timezone
Field export/preview | Validation warnings | Confirmation/Receipt
Amendment allowed/until | CurrentState | Contact/Incident refs

اگر Portal خراب شد، evidence بسازید نه bypass

خطا، timestamp، field، browser و screenshot کمینه‌شده را ثبت و از contact رسمی کمک بگیرید. CAPTCHA، geo restriction یا deadline را با راه ناامن، account قرضی یا جعل location دور نزنید. email submission فقط اگر organizer تأیید کرد معتبر است. receipt نگرفتن را «حتماً ثبت شده» فرض نکنید.

Decision State چندحالته است

• Submitted/Under review؛
• Needs clarification/Revision requested؛
• Accepted/Conditionally accepted؛
• Waitlisted/Alternate؛
• Rejected/Out of scope/Ineligible؛
• Withdrawn/Cancelled/No decision/Unknown.

email واقعی و portal را با phishing awareness بررسی کنید. Acceptance ممکن است deadline کوتاه برای confirm، agreement، registration، disclosure یا material داشته باشد. پذیرش مشروط را قطعی اعلام نکنید و schedule عمومی را تا تأیید organizer فرض نکنید.

Feedback داوری Observation است، نه حقیقت نهایی

comment را به criterion/field وصل کنید و مشخص کنید reviewer متن را اشتباه فهمیده، evidence کم بوده یا با premise مخالف است. همه feedbackها سازگار یا قابل اقدام نیستند؛ reviewer context محدود دارد. از comment برای حمله به داور یا اثبات بی‌عدالتی استفاده نکنید. در صورت وجود route رسمی clarification/appeal، scope و deadline آن را رعایت کنید.

FeedbackID | Submission/Version | Stage/Source (if known)
Criterion/Field | Exact observation | Interpretation
Evidence/Conflict | Action[adopt,adapt,clarify,reject,unknown]
Reason | ChangeVersion | Recheck | Privacy/Publication basis

رد شدن، ضعف ایده یا نزدیک‌شدن قطعی به بله نیست

رد می‌تواند از fit، capacity، balance، eligibility، review concern، overclaim یا عوامل نامعلوم بیاید. «هر نه یک قدم نزدیک‌تر به بله» تسلی است، نه evidence. تصمیم را ثبت، feedback را محدود تحلیل و درباره revise، retarget، pause یا retire تصمیم بگیرید. سلامت و زمان submitter را نیز هزینه واقعی حساب کنید.

Resubmission یعنی Requalification کامل

ارسال همان متن به رویداد دیگر لزوماً ممنوع یا بد نیست؛ policyها متفاوت‌اند. اما CFP Snapshot، audience، fieldها، anonymity، outcome، format، cost و evidence cutoff باید دوباره بررسی شوند. simultaneous submission، prior presentation/publication و duplicate rules را رعایت کنید. نام رویداد را عوض‌کردن customization نیست.

پس از پذیرش، Submission Contract را با Talk همگام کنید

محتوا در preparation رشد می‌کند، اما title/abstract/outcome و format وعده عمومی‌اند. تغییر scope، speaker، claim، demo یا commercial content را طبق organizer approval مدیریت کنید. proposal پذیرفته‌شده را baseline و تغییرها را trace کنید؛ سپس Runbook اجرای مقاله سخنرانی فنی QA را بسازید.

مثال کاملاً ساختگی برای کنفرانس QA

Fixture SYN-CFP-QA-01 یک CFP و رویداد خیالی با deadline، reviewer و portal ساختگی است. proposal درباره Checkout آفلاین جعلی با Order، PaymentAttempt، PSP Stub، Callback، Ledger و Reconciliation است. هیچ کنفرانس، organizer، reviewer، speaker، employer/client، submission، case، repository، سیستم، کاربر، order/payment/PSP/bank/account/card/token/credential/PII یا پول واقعی ندارد.

داده lab شامل IRR و تومان صرفاً نمایشی/برچسب‌دار، رقم فارسی/عربی/لاتین، ی/ی و ک/ک، ZWNJ/RTL-LTR/Bidi، UTC/Asia-Tehran و جلالی صرفاً نمایشی؛ timeout پیش/پس از fake commit، retry، duplicate، late و reordered event است. هیچ ادعای قانونی، بانکی، امنیتی، پذیرش، review fairness، accessibility conformance یا outcome واقعی صادر نمی‌شود.

Validator ساختگی: عنوان جذاب و ۵ Takeaway کافی نیست

یک validator مستقل از شبکه با Node.js ساخته شد. checker سطحی دید: title جذاب، abstract دویست‌کلمه‌ای، پنج takeaway، bio باتجربه و submission قبل از deadline؛ سپس به‌اشتباه WINNING_PROPOSAL_ACCEPTANCE_READY داد. ممیزی ساختاری دقیقاً ۴۰۱ کنترل یکتا در گروه‌های Identity، CFP، Snapshot، Deadline، Eligibility، Obligation، Review، Rubric، Track، Audience، Problem، Claim، Evidence، Outcome، Abstract، Outline، Format، Feasibility، Speaker، Integrity، Permission، Disclosure، Accessibility، Locale، Preflight، Submission، Decision، Feedback، Revision و Limits پیدا کرد و HOLD-401 داد.

قاعده مستقل تأیید کرد fixture هیچ رویداد، organizer، reviewer، speaker، submission، case، سامانه یا پذیرش واقعی ندارد. پس از pin شدن همه کنترل‌های داستانی، نتیجه فقط READY_FOR_CONFERENCE_PROPOSAL_REVIEW-0 بود؛ نه تضمین پذیرش، کیفیت ایده، review fairness، eligibility واقعی، مجوز انتشار، feasibility سفر/اجرا، audience value یا Session success.

۲۶ ضدالگوی پروپوزال کنفرانس

• پروپوزال را بلیت صحنه یا هنر فروش دانستن؛
• وعده حداکثرشدن شانس پذیرش؛
• استفاده از راهنمای سال قبل به‌جای CFP جاری؛
• فرض قالب/طول استاندارد جهانی؛
• بی‌توجهی به timezone و deadline portal؛
• نوشتن کامل پیش از Eligibility/Cost check؛
• Review score را با Selection یکی‌کردن؛
• Blind را ناشناس‌ماندن کامل فرض‌کردن؛
• انتخاب Track برای رقابت کمتر؛
• Archive را حکم تکراری/نو بودن دانستن؛
• ادعای «اولین/تنها» بدون universe؛
• Problem عمومی و درد نمایشی؛
• planned work را نتیجه completed نوشتن؛
• Case واقعی با نام مستعار بدون permission؛
• Title clickbait/keyword-stuffed/تضمینی؛
• Abstract عمومی را private فرض‌کردن؛
• Takeaway را topic list نوشتن؛
• Outcome ناممکن در format/time؛
• Workshop بدون setup/support/alternative؛
• Engagement را poll یا Q&A صرف دانستن؛
• Bio/prestige را evidence صحت گرفتن؛
• Co-speaker تزئینی یا بدون consent؛
• پنهان‌کردن AI/commercial/funding/conflict؛
• Supplemental link ناقض blind/access/privacy؛
• Submit بدون preview/export/receipt؛
• هر رد را شکست یا قدم قطعی به پذیرش بعدی دانستن.

چک‌لیست ۳۲ مرحله‌ای Submitter

• CFPID/edition/year و Official URL درست است.
• Snapshot/timezone/hash و change log ثبت شده‌اند.
• deadline بیرونی و داخلی قطعی‌اند.
• Eligibility همه contributorها pass است.
• prior/simultaneous/duplicate policy بررسی شده است.
• registration/travel/visa/cost feasibility روشن است.
• تعهد training/agreement/material deadline پذیرفته است.
• Review versus selection model فهمیده شده است.
• blind fieldها و identity leak بررسی شده‌اند.
• rubric-to-field trace کامل است.
• Track و why-this-event مستدل‌اند.
• Audience/prerequisite/context مشخص‌اند.
• Problem محدود و بدون اغراق است.
• Claim type/status/cutoff date درست است.
• Evidence/source/uncertainty/limitation آمده‌اند.
• Title با rules و promise هم‌راستاست.
• public abstract برای attendee دقیق است.
• reviewer description روش/feasibility را نشان می‌دهد.
• Outcome observable و deliverable است.
• Takeaway با Outcome و Evidence align است.
• Outline زمان، interaction، Q&A و buffer دارد.
• Format با Outcome تناسب دارد.
• Demo/workshop dependency و fallback دارد.
• Accessibility و alternative مسیر دارد.
• Speaker contribution/consent/availability ثبت شده است.
• NDA/IP/privacy/security/license pass است.
• AI/authorship/citation policy رعایت شده است.
• commercial/funding/conflict disclosure کامل است.
• Locale/translation/Unicode/limit در portal آزموده است.
• Independent preflight همه fieldها را دیده است.
• Preview/export/version/hash قبل submit ذخیره شده‌اند.
• SubmissionID/timestamp/confirmation/receipt تأیید شده‌اند.

پایلوت ۳۰روزه بدون ارسال واقعی

روز ۱ تا ۵: یک CFP خیالی با field، deadline، rubric و obligations بسازید. روز ۶ تا ۱۰: Eligibility، Review Model و Rubric Trace را کامل کنید. روز ۱۱ تا ۱۵: Idea Brief، Claim/Evidence و Permission pack را بنویسید. روز ۱۶ تا ۲۰: Title، Abstract، Outcomes، Takeaways و Outline را field-by-field بسازید. روز ۲۱ تا ۲۵: Format/Feasibility/Accessibility/Speaker/Disclosure را audit کنید. روز ۲۶ تا ۳۰: Portal fake، preflight، receipt، rejection feedback و resubmission را تمرین کنید.

قالب نهایی Conference Proposal Submission Record

ProposalID/Version/Owner | CFP Snapshot/Deadline
Eligibility/Obligations/Review/Rubric/Track
Audience/Problem/Claim/Evidence/Limits | Title/Public Abstract
Outcomes/Takeaways/Outline/Format/Feasibility/Accessibility
Speaker/Contribution/Permission/Integrity/Disclosure/Locale
Preflight/FieldExport/Hash | Submission/Receipt/Amendment
Decision/Feedback/Revision/Resubmit/Withdraw/Retention

جمع‌بندی: پروپوزال خوب یک قرارداد صادقانه و قابل تحویل است

نوشتن پروپوزال کنفرانس تست نرم‌افزار از Title شروع نمی‌شود. CFP جاری را snapshot کنید، eligibility و تعهد را بسنجید، review/selection را بفهمید، audience/problem را محدود، Claim را به evidence وصل و outcome را با format/time سازگار کنید. سپس permission، authorship، disclosure، accessibility و fieldها را مستقل audit کنید و receipt بگیرید. پذیرش در کنترل کامل شما نیست؛ صداقت، fit، traceability و قابلیت تحویل هستند.

سؤالات متداول نوشتن پروپوزال کنفرانس تست

طول مناسب Abstract و Proposal چقدر است؟

فقط CFP و counter همان portal پاسخ معتبر می‌دهند. یک رویداد word limit و دیگری character limit یا چند field مستقل دارد. توصیه عمومی ۱۵۰–۳۰۰ یا ۵۰۰–۱۰۰۰ کلمه را جایگزین rule رویداد نکنید.

چگونه بفهمم ایده‌ام برای کنفرانس تکراری نیست؟

CFP، Track و archive رویداد و منابع مرتبط را با دامنه جست‌وجوی ثبت‌شده بررسی کنید؛ سپس تفاوت context، evidence، method، failure یا outcome را دقیق بنویسید. نبود نتیجه اثبات novelty و وجود موضوع قبلی دلیل رد خودکار نیست.

آیا GitHub، اسلاید یا ویدیو را به پروپوزال لینک کنم؟

فقط اگر CFP/field اجازه و purpose روشنی دارد. blind review، identity، access، link expiry، permission، NDA، license و reviewer burden را بررسی کنید. public بودن repository دلیل ارتباط، صحت یا حق انتشار نیست.

اگر پروپوزال رد شد، آیا همان را برای رویداد دیگری بفرستم؟

ابتدا prior/simultaneous submission policy را بررسی کنید. سپس CFP، audience، Track، field، anonymity، outcome، format، cost و evidence cutoff را دوباره qualify کنید. گاهی revise، گاهی retarget و گاهی retire انتخاب درست است.

آیا استفاده از AI برای نوشتن Abstract مجاز است؟

قاعده عمومی ندارد؛ policy همان رویداد و ابزار را بخوانید. محتوای محرمانه وارد نکنید، disclosure لازم را انجام دهید، citation/copyright را رعایت و همه ادعاها را انسانی بررسی کنید. ابزار مسئول خطا یا submission نیست.