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 Done 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? We do not advertise support for alternative boolean options in our documentation, which follows spec guidance What should they say? 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? We do not advertise support for alternative boolean options in our documentation, which follows spec guidance  What should they say? 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) Drivers spec says it's RECOMMENDED that we allow the listed alternate values for true and false to be supported, however it is not REQUIRED. The spec also says that these alternate values should be removed from our documentation and examples and that we should emit a warning if they are used (note that we do emit this warning currently, so our users should already be aware that these alternates are deprecated) Are any clarifications or revisions needed? No If applicable, what do other drivers do? If there is no common spec, is a common spec needed? What should the behavior be? 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? Users who have disregarded the warnings emitted by the driver on the deprecation of the alternative values for booleans. It is unlikely that these users will be moving to the latest version of the driver, and if they do, since this will be a major version bump, a breaking change like this will be expected. Why might users care about this change? It will now throw at option parse time when starting up applications. 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) Shell will need to update any uses of alternate boolean values that exist Update follow up requirements and create subtasks for follow up or coordination actions Done What variables affect the feature in question? Server versions Deployment types Auth settings Server and client configuration options Only affects boolean options provided in the connection string Specific apis / api options Runtime or bundler settings Special sequences of operations Any other special conditions How should all the identified variables be tested? Identify happy path and error case combinations of variables Given boolean options, when the alternate values are provided in the connection string, the options parser should throw an error  How will we achieve the necessary coverage for these cases? Automated spec tests? Are there test runner changes required? Possibly: we have spec tests (connection-options) that assert that we accept an alternate boolean value and emit a warning How up to date are our current tests and runners? We need to sync some of our connection-string and connection-option tests New integration or prose tests? Unit tests? May need to add unit tests to ensure that we throw on alternate boolean values in connection strings Will we need to modify any existing tests? Yes, see note on runner changes Is there technical debt that will affect the implementation of new or existing tests? No Do we have the necessary tooling infrastructure already in place for any new tests? Yes 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 node driver, should only be in src/connection_string.ts 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? Negligible Do we have existing performance coverage for the affected areas? Do we need to add new coverage? No Update ticket test AC and create subtask(s) as needed Consider backport requirements Should this be backported? No, this is breaking 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 Done Double check the documentation requirements Done Double check the task breakdown to ensure it covers all actionable items in the ticket AC Done

1. What would you like to communicate to the user about this feature? This change will require users to explicitly provide true or false when specifying values for Boolean options in both connection string and the MongoClient constructor 2. Would you like the user to see examples of the syntax and/or executable code and its output? No, we will have a code example in the release notes. 3. Which versions of the driver/connector does this apply to? >= v6