Merge pull request #19752 from wordpress-mobile/feature/add-nullabili…

…ty-step-to-converting-to-kotlin-doc

Add nullability recommendation to the "Converting to Kotlin" documentation

docs/converting-to-kotlin.md

@@ -14,11 +14,17 @@ When converting a file from Java to Kotlin, ensure you enable this option in And
 1. The first commit will involve a simple rename from `.java` to `.kt`.
 2. The second commit will rename the `.kt` extension back to .java, followed by the actual commit.
 
-**Reason**: Enabling this option helps the reviewer perform a diff on the second commit, showing precisely what changes occurred between the Java and Kotlin files. Otherwise, the PR will display a file deletion (`.java` file) and a file addition (`.kt` file), making it challenging for the reviewer to diff effectively.
+**Reason:** Enabling this option helps the reviewer perform a diff on the second commit, showing precisely what changes occurred between the Java and Kotlin files. Otherwise, the PR will display a file deletion (`.java` file) and a file addition (`.kt` file), making it challenging for the reviewer to diff effectively.
+
+### Consider adding nullability annotations before initiating automatic conversion:
+
+Address the warnings of "Missing null annotation" before starting automatic conversion.
+
+**Reason:** This makes automatic conversion to handle nullability instead of setting everything to nullable.
 
 ### Depend on automatic conversion and commit immediately:
 
 When performing the conversion, rely on the automatic conversion tools and commit the changes promptly, even if the resulting Kotlin code doesn't compile. Subsequently, on another commit, you can refine the Kotlin code, making it more idiomatic or addressing any compilation issues, such as adding nullable checks (`!!` or `let`).
 
-**Reason**: This approach informs the reviewer and other readers that the first commit involved an automated conversion without manual intervention. It helps establish that any code refinements occurred separately, providing clarity on the development process.
+**Reason:** This approach informs the reviewer and other readers that the first commit involved an automated conversion without manual intervention. It helps establish that any code refinements occurred separately, providing clarity on the development process.