Paper Submission

Content Guidelines

• Along with the paper, it is mandatory to submit the code that generated the submitted runs. Instructions on how to submit the code are given below.

• The paper title must follow the following template: <Team_Name> at Qur'an QA 2023 Shared Task: <Own_Title>. An example title is "bigIR at Qur'an QA 2023 Shared Task: Using ColBERT for Finding Relevant Answers to Questions from Qur'an".

• Each team can submit one paper even if it participates in both subtasks.

• The page limit is 4 pages according to the conference guidelines.

• The paper should cover the following sections:

  • Abstract: four/five sentences highlighting your approach and key results.

  • 1. Introduction: ¾ a page expanding on the abstract mentioning key background such as the task definition, why the task is challenging for current modeling techniques, and why your approach is interesting/novel.

  • 2. Data: review of the data you used to train your system. Be sure to mention the size of the training, validation/dev, and test sets that you’ve used, and the label distributions, as well as any tools/extenral resources you used for preprocessing data.

  • 3. System: a detailed description of how the systems were built and trained. If you’re using a neural network, were there pre-trained embeddings, how was the model trained, what hyperparameters were chosen and experimented with? How long did the model take to train, and on what infrastructure? Linking to source code is valuable here as well, but the description should be able to stand alone as a full description of how to reimplement the system. While other paper styles include background as a separate section, it’s fine to simply include citations to similar systems which inspired your work as you describe your system.

  • 4. Results: a description of the key results of the paper. Results on the dev set, official results on the test set, analysis of the results, etc. You can also report and analyze the results of other runs that you didn’t officially submit. If you have done extra error analysis into what types of errors the system makes, this is extremely valuable for the reader. 

  • 5. Discussion: general discussion of the task and your system performance. Description of characteristic errors and their frequency over a sample of development data. What would you do if you had another 3 months to work on it?

  • Conclusion: a restatement of the introduction, highlighting what was learned about the task and how to model it.

• If you participated in both tasks, you can have subsections within sections 2-5, or you can repeat sections 2-5 for each task separately.

• For ease of approach reproducibility (and faster learning by others), you are strongly encouraged to release your code and make it publicly available. If so, please indicate that in your paper and provide a public link.

• Please pay careful attention to the "Anonymity" section in the formatting guidelines below.

Code Submission Guidelines

• Put your code files into a .zip file.

• Add a readme file within the zip file that explains your code structure and how to replicate the results reported in the paper.

• On the submission page of OpenReview, you can upload the code within the "Supplementary Materials" section.

Formatting Guidelines

Please follow the formatting guidelines/instructions detailed on the conference website before submitting your paper.