Checklist for JS or ETS development

Topic	Description	Identification method
Code Structure	Here there are 2 parts :- 1. Code structure for library and application as per openHarmony guidelines. 2. Imported library structure	A base template for application and library can be created based on the latest IDE and SDK and compare the params based on this
SDK and tool chain	Always use the latest SDK and buildtools for development	build-profile.json5 will have this information about the hap classpath and the sdk version used.
Static tool report	Static reports will be generated on sonarcloud based on Checkstyle provided	1. All critical and major issues should be handled. 2. Minor and info to be discussed and handled.
Configurations	Make sure there are no dependencies added which are not used by the library or application	Check package.json in project and module folders
Test folders	UT is a mandatory requirement, but if there is any reason after approval UT cases are not done, make sure dead folders are not there in project	Check the test folders in library and sample application
Test cases	Identify enough test cases for each functionality provided by the library and all the negative scenarios are tested to make sure the system handles them gracefully	During release this artifact is a mandatory requirement
Copyright	1. For the new files we add applib group copy right. 2. For the modified files we will retain the existing copy right. 3. In case modified files don't have copy right existing, then keep it like that. Keep the status quo.	Compare the files from original library and follow this rule
License	1. For the new files, Apache 2.0 license information to be added [refer]. Also make sure license added in all JS,ETS and JSON files 2. Add the Apache 2.0 license file from here in your repo. 3. For the modified files Apache 2.0 license information can be added additionally considering the compatibility of original licnese (MIT)
ReadMe	1. Should follow the base library and also the license. 2. Main point to focus is source information from where we have forked this lib.	1. Please refer sample readme here 2. Make sure don't use keywords like HarmonyOS, Android, HMOS etc..in readme documentation. 3. In readme, update npm details with the same library name eg: @ohos/<'lib name'>
Library Name	Library name should not contain keywords like "hmos","ohos","harmonyos","android" and symbol "_'	1. In libs package.json, define the library name to start with @ohos/<'name'>. 2. Don't add the lib dependency in top-level package.json 3. Add Lib dependency in entry folder's package.json
Android Name changes	1. Library name: Replace android prefix or post fix with ohos. 2. Library name the spelling should be kept intact same as original library including the cases. Ex1: zxing_android -> zxing_ohos. Ex2: zxing -> zxing android_zxing -> ohos_zxing	Ex1: action_ios -> action_ohos Ex2: action_android -> action_ohos Ex3: ios_action -> ohos_action Ex4: android_action -> ohos_action
Code style	1. All string resource translations to be added in chinese language also. 2. All dimension values should use 'vp', and font values should use 'fp'
Check the new comments added	1. Any new comment added should make sense and give some info. 2. In the same way if new logic is added add proper comment
Logs	1. We should not add unneccesary logs or debug logs. 2. Logs should not print sensitive information.
TODO's	Only valid TODO's to be added
Generated files	Any tool chain generated code should not be added to github.	1. Apart from basecode all the generated code should be avoided like .idea folders 2. We can create .gitignore which should handle basic files but as reviewer we can double check this.
Clean up Code	1. Remove code which is not relevant for openHarmony, like android util class or resources etc., which are not useful in openharmony 2. Need to do code formatting. Use ctrl + Alt + L to each code files.
DCO signing and CLA	All contributors must sign the Developer Original Statement before they can participate in community contributions. 1. Refer sheet for the keywords and errors which CI may raise during PR submission	Sign the DCO with your mail id that going to be used for contribution
QA for third-party library development	Quality requirements and suggestions for the development of the third-party library.	Refer document for the quality guidelines which need to be followed for third-party library development