Process for contributing new code

Here's an overview of the process we follow to contribute new code to the sidewalk repo. As you write code, also make sure to follow our style guide.

develop Branch for Resolving Issues

The production server, projectsidewalk.io, runs the main master branch of the git repo which contains stable code. For adding new features, fixing issues and bugs, we have another branch called develop. When you start to work on an issue, you need to create a branch for your work from the develop branch (since it has the latest code).

Issue Branch Naming Conventions

To name your branch, follow this convention:

<git-issue-no>-<brief-description>

E.g. You are implementing a fix for this issue: https://github.com/ProjectSidewalk/SidewalkWebpage/issues/474

So the name of the branch would be: 474-admin-update-activities-table

This nomenclature helps to automatically add a label 'work-in-progress' to the issue you are working on when you publish the branch to the repo and provides a good descriptive branch name.

Testing your Contribution

To test out changes that will affect different users in different ways, you should test your code locally.

1. To login as a normal user: Simply create an account and login via the "Sign in" button in the top right of the page.
2. To login as a mechanical turk user, visit localhost:9000/?referrer=mturk&hitId=h1&workerId=worker1&assignmentId=a1&minutes=60 instead of localhost:9000. If you the session you made for that user times out, you can just change the workerId, hitId, and assignmentId in the URL to start an account for a new turker. If you want another session with the same user, just change the hitId and assignmentId.
3. To login as a researcher/admin, you have to manually change your role id. To do this, open the user_role table in the database, and change the role_id corresponding to your user_id to 3 (Researcher) or 4 (Administrator). These IDs are defined in the role table.
   • To find your user_id, you can search through the sidewalk_user table entries for your username.
4. If you are modifying the validation interface, you will want to test on mobile as well. To test on your mobile device, find you IP address using ipconfig. Then go to <ip_address>:9000 on your mobile device instead of localhost:9000.
5. Does your code change or add any new text that users see? If so, post in the Github issue thread with all the changes/additions in English and ask for translations into Spanish so those can be added with your PR. Then add both the English and Spanish versions. You can find examples of how to do it in both HTML and JavaScript throughout the code, but it will looks something like this:
   1. If you are adding to the HTML, add a line to both conf/messages.en and conf/messages.es with the translations, and reference those in the HTML file using @Messages("your.translation.id").
   2. If you are adding to JavaScript, add the translations to the appropriate files in public/locales and reference them in the JavaScript using i18next.t('your-translation-id').
6. The last thing to do before creating a PR is to pull the most recent changes from on the develop branch into your own branch using git pull origin develop. Then test your changes on last time using this updated code, push that merge commit to your branch on Github, then create a PR.

Submitting PRs

Finally, when you submit a pull-request that will be reviewed before we merge it with develop branch (and consequently to master branch), write descriptive titles and include the issue number (e.g. #408: <PR Title>) in the title. Finally, in the pull request description, mention the following things:

1. "Resolves/Fixes <#issue-number>": Write either the words "Resolves" or "Fixes" along with the issue/bug number. It needs to be added when you create the PR. This will automatically add the "pull-request-submitted" label to the issue you are working on and to the pull request. For an example, see this PR.
2. Add a brief description of the main changes you made and if it would have any side-effects to other parts of the application. Again, refer to the previous example for reference. Additionally, it is always nice if you give instructions to other users on how to test your changes.

The automatic labeling ('work-in-progress' or 'pull-request-submitted') is done by waffebot that we use for managing issues. Hence, the requirements. Ask before closing an issue associated with a pull-request. The protocol is to test the fix on both the issue branch and develop before closing the issue.

Things to keep in mind:

1. Keep the PR small - only related to the issue in hand. Don't try to solve too many issues in one PR.
2. Before submitting PRs for UI related issues, provide a before and after screenshot in the issue thread first. The team will provide their comments and we will come to a conclusion there. Then submit the PR. The PR thread should be reserved for all comments related to the implementation and things that come during testing.