> For the complete documentation index, see [llms.txt](https://docs.openreview.net/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openreview.net/how-to-guides/workflow/how-to-enable-commenting-on-submissions.md).
# How to Enable Commenting on Submissions
Venues created with the Conference Review Workflow include an **Official Comment** step in the [Workflow Timeline](/getting-started/hosting-a-venue-on-openreview/navigating-your-venue-pages.md#workflow-timeline). By default, commenting opens 4 weeks after the submission deadline (the full submission deadline, if your venue has one) and closes 6 weeks after it. The Program Chairs, assigned Senior Area Chairs, assigned Area Chairs, assigned reviewers, and the submission's authors can post comments, and the person commenting chooses who can read each comment.
To change when and how commenting is enabled, click **Official Comment** in the Workflow Timeline to expand the step, then use the **Edit** link next to each control and click **Submit**.
## Set when commenting is open
Edit **Dates**:
* **Activation Date** – when the comment form becomes available on each submission.
* **Expiration Date** – when the comment form is no longer available.
## Choose who can comment and who can read comments
Edit **Writers And Readers**:
* **Writers** – "Who should be able to participate in this stage (read and write comments)?" Choose from Program Chairs, Assigned Senior Area Chairs, Assigned Area Chairs, Assigned Reviewers, Assigned Reviewers who already submitted their review, and Submission Authors. Program Chairs are always included.
* **Readers** – "Who should be able to only read comments?" These are the reader options commenters can choose from. Program Chairs are always included.
Senior Area Chair and Area Chair options only appear if your venue has those roles.
The Official Comment step, as Program Chairs see it, with the Writers And Readers editor open.
## Choose who is notified
Edit **Notifications** and select which groups are emailed when a comment is posted. By default, assigned reviewers and submission authors are notified. An email is only sent to a selected user if they are also a reader of the comment.
## Change the comment form
Edit **Form Fields** to add, change, or remove fields of the comment form. See [How to modify the Review, Meta Review, and Decision Forms](/how-to-guides/workflow/how-to-modify-the-review-meta-review-and-decision-forms.md) for how the form editor works.
{% hint style="info" %}
**Public** is not one of the reader options of the **Official Comment** step, and comments from users outside your venue's committee (public comments) cannot be turned on from the Workflow Timeline. To allow either, contact OpenReview Support by posting a comment on your [venue request form](/getting-started/hosting-a-venue-on-openreview/navigating-your-venue-pages.md#venue-request-form).
{% endhint %}
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.openreview.net/how-to-guides/workflow/how-to-enable-commenting-on-submissions.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
