# Submitting Amendments

Before submitting any change to the list, please make sure to read the [Guidelines](https://github.com/publicsuffix/list/wiki/Guidelines).

A properly formatted and validated patch will decrease the review time and increase the chances that your request will be reviewed and perhaps accepted. Any patch that doesn't follow the Guidelines will be rejected or, in the best scenario, left pending for follow-up.

The most common time loss comes from not following the sorting guidelines.

- Sorting / Placement needs to comply with [Guidelines](https://github.com/publicsuffix/list/wiki/Guidelines)

- *PLEASE* order within the existing entries in the PRIVATE DOMAINS section so that your listed organization on your first comment line is alphabetically sorted
  - Do NOT append your PRIVATE DOMAINS entry to the end of the file
  - If there is more than one domain within your PR, order your entries alphabetically, ascending by TLD, then SLD, then 3LD and deeper, etc. (if present).

Other common mistakes that may cause the request to be rejected include the following:

- Invalid patch formatting, rule sorting, or changeset position (see this: [Wiki:Formatting](https://github.com/publicsuffix/list/wiki/Format))
- Missing validation records 
- Lack of proper domain ownership or expiry dates less than 2Y away
- Attempts to work around vendor limits (see [#1245](https://github.com/publicsuffix/list/issues/1245) as an example)
- Submissions with TLDs non-compliant with [ICP-3](https://www.icann.org/resources/pages/unique-authoritative-root-2012-02-25-en) or on the [ICANN PSL](https://github.com/publicsuffix/list/wiki/Security-Considerations#icann-public-suffix-list)
- Insufficient or incomplete rationale (be verbose!)
- Smaller, private projects with <2000 stakeholders

Frequently, PR submissions overlook the sort ordering guidelines, adding to the delay in processing and increasing the time it takes to process requests.

Make sure to review the [Guidelines](https://github.com/publicsuffix/list/wiki/Guidelines) before you open a new pull request.

Please also note that there is no guarantee of inclusion, nor are we able to provide an ETA for any inclusion request. This is also true of projects that incorporate the PSL downline. This is described, outlined, and diagrammed [here](https://github.com/publicsuffix/list/wiki/Guidelines#appropriate-expectations-on-derivative-propagation-use-or-inclusion).

Before you attempt to make a contribution or comment, please read the [Mozilla Community Participation Guidelines](https://www.mozilla.org/en-US/about/governance/policies/participation/).

## PSL Mailing List

We suggest that submitters and users/integrators of the PSL join the (low-traffic) mailing list to be aware of changes to structure, processes, or formatting.

Some future changes may include automation of DNS tests for the presence of `_PSL` in `#PRIVATE` section entries to indicate ongoing inclusion or remove entries that do not have them, possible file structure, or other changes. The "list list" is located [HERE](https://groups.google.com/g/publicsuffix-discuss)
