Review the ticket description for general accuracy and completeness

• Bug - Confirm that the bug still exists
• Task / Feature / Improvement - Ensure every section of the template is filled out and makes sense
• Build failure - Investigate and confirm the cause of the build failure
• Spec change - Check whether any more recent changes have been made to the spec that might affect the implementation requirements

What is the expected behavior?

• What do the official driver or server docs currently say about this functionality? Nothing, these options were removed in v4
  • What should they say? Nothing, we will have a mention of the warning in release notes and "what changed" on mongodb manual
    • If revisions or additions are needed, mark the ticket as docs changes needed and fill out the doc changes form
• What do our api or readme docs currently say about this functionality? Nothing
  • What should they say? Nothing
  • Capture any revisions or additions in the ticket documentation AC
• If applicable, what does the common drivers spec say? (Note: your kickoff partner should independently review the spec) Not a common spec option
  • Are any clarifications or revisions needed? None
• If applicable, what do other drivers do? Other drivers do not have this option
  • If there is no common spec, is a common spec needed? No
• What should the behavior be? Emit a deprecation warning
• Update the ticket description and implementation requirements as needed

Review and address any unknowns explicitly called out in the ticket

What will be the impact on users?

• Who will be impacted? Any users still passing these legacy options into MongoClient via options object or connection string options
• Why might users care about this change? It emits a warning to their terminal / logs
• Capture relevant detail in the "User Impact" section of the ticket description

What will be the impact on any downstream projects? (e.g., shell, mongoose)

• Update follow up requirements and create subtasks for follow up or coordination actions
• Possible workarounds for preventing the warning from printing to stderr if that is desirable.

What variables affect the feature in question?

• N/A - entirely unit testable, same for all node versions
• Server versions
• Deployment types
• Auth settings
• Server and client configuration options
• Specific apis / api options
• Runtime or bundler settings
• Special sequences of operations
• Any other special conditions

How should all the identified variables be tested? No variables

• Identify happy path and error case combinations of variables
  • Given [variables], when [action is performed], [feature] should [behave in the expected way]
• How will we achieve the necessary coverage for these cases?
  • Automated spec tests?
    • Are there test runner changes required?
    • How up to date are our current tests and runners?
  • New integration or prose tests?
  • Unit tests? Yes, only a unit test
• Will we need to modify any existing tests?
• Is there technical debt that will affect the implementation of new or existing tests?
• Do we have the necessary tooling infrastructure already in place for any new tests?
• Update test requirements on the ticket to reflect reality
• Create subtasks for any testing groundwork that can happen independently of the implementation

What is the scope of the code changes?

• List the code bases and the areas of each code base that will need changes
  • driver
• Is there technical debt in any of these areas that will affect the implementation?
  • no
• Identify any existing adjacent functionality that could be impacted by these changes
  • Is there sufficient existing test coverage for the adjacent functionality?
    • Update ticket test AC and create subtask(s) to cover existing functionality if coverage is missing
• If multiple libraries are affected, determine the order in which changes need to go in
• Create subtasks for the implementation (at least one per affected codebase)

What is the expected impact on performance? None

• Do we have existing performance coverage for the affected areas?
• Do we need to add new coverage?
  • Update ticket test AC and create subtask(s) as needed

Consider backport requirements

• Should this be backported? No
• What would be the cost of a backport?

Is the metadata of this ticket accurate and complete?

• Double check the acceptance criteria to ensure it accurately captures the expected behavior, test, and follow-up requirements
• Double check the documentation requirements
• Double check the task breakdown to ensure it covers all actionable items in the ticket AC

1. What would you like to communicate to the user about this feature?

• These options are unused, our driver now prints a warning if they are specified
• The options do not change any functionality in the driver (they have not since v4)

2. Would you like the user to see examples of the syntax and/or executable code and its output?

• This probably just needs to be near the top of the "what changed" in the v6 release. We suspect a good portion of users will start seeing this warning, and we'd want them to be reassured that there isn't anything broken.

3. Which versions of the driver/connector does this apply to?

• v6