Contributor Guidance

This is feedback from contributors who review code contributions and contains some suggestions that could make the role of reviewer easier. These are suggestions for discussion and not rules (yet).

Getting started

Make sure all client side pre-requisites are installed.
Clone the repository if you have write access. Otherwise, fork the repository and clone the fork.
Create a branch for the contributing work.
Run yarn at top level of the repository to install all dependencies.
Run yarn build to compile and build the packages.

Testing changes

After changes are added and have been compiled and built, use VS Code's debugger to test changes. Choose the debugger according to the changes made:
- Run Zowe Explorer VS Code Extension for changes to the zowe-explorer package.
- Run Zowe Explorer FTP VS Code Extension for changes to the zowe-ftp-explorer package.
If the debugger is already running and new changes are introduced to the package that's running in debugger, restart the debugger to see the changes.
If changes are introduced to the zowe-explorer-api package, run command yarn build to bring in changes to the VS Code extensions and restart the debugger.

Keybinding reference chart for different OSs/apps

Use the reference chart to assist when deciding on a new keybinding for an action in VS Code. https://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts

Review and Merge guidance for contributors

When creating the PR

Suggestion here: Follow the guidelines below when opening a Draft Pull Request. Once you have run the checks in the draft pull request, select Ready for Review.

Ensure a descriptive title. e.g. Issue # + Description
Tag Issues and PRs in linked Pull Request section
Tag the milestone as specified in the originating Issue
Add labels, where appropriate to aid in prioritization
Make sure that All Checks (DCO and Jenkins Run) are okay. If there are issues that you cannot handle, comment it in the PR.
Please try and address only one fix per PR. Multiple fixes in one PR makes things more complicated for everyone.
PR must relate to an issue agreed during Planning for the target milestone or in the prioritized backlog. I concede this may not apply to external contributors as we are always grateful for new contributors and don't want to put anyone off getting involved.
Please... No direct messaging to solicit review/merging.
Reduce number of commits per PR. It can be frustrating if requested to review and subsequently complete the review request only to find several additional commits have taken place.
If raising the PR to see if checks pass or as WIP raise as a Draft. It will not be reviewed and when you are comfortable with it you can close the draft and raise again for review

Reviewers

Aim for a minimum of 2 approvals rather than 1.
Prioritize merging of PR's based on complexity and target milestone.
Generally merging will be by agreement of several reviewers rather than one individual.
When filtering the PR list use recommend using is:pr is:open status:success rather than waste time reviewing PR's that are incomplete.

Overall code refactoring effort

The addition of an interface allows the code base to move to a more maintainable OO style based around, classes and methods rather than functions. To this end no code should be added as functions in extension.ts or the ..Actions.ts files. Code migration is still underway to create generic command related methods and some issues experienced merging changes previously however we should now be able to manage at a function to method level now the previous changes are solidified.

Testing

Effort is underway to include System test into pipeline build.
Unit test code coverage. Must maintain +90% currently dropped to 91% using CodeCov may be problematic so before commiting you should check your local unit test coverage matrix. For example the % Lines for the All Files row
- We should not rest until all files have >90% lines covered