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. This is broadly the process that you will follow when you're ready to write code for a new ticket while using git through the command line (though you can do the same things through Github Desktop):

$ git checkout develop                                            // always make sure to branch off of develop
$ git pull                                                        // make sure you have the most recent code from the repo
$ git checkout -b <branch-name>                                   // see branch naming convention section below
$ git push origin <branch-name>                                   // push your branch to Github for the first time
$ git branch --set-upstream-to=origin/<branch-name> <branch-name> // connect local branch to the one on Github
$                                                                 // write some code
$ git status                                                      // see what you changed; ignore changes to docker-compose.yml and .ivy2/ files
$ git diff <filename>                                             // use on each file you edit to ensure you don't commit something accidentally
$ git add <filename>                                              // if the changes look good, git add "stages" the file for commit
$ git commit -m "descriptive message"                             // commit the changes to the files you staged to your local branch
$ git push origin <new-branch-name>                               // push your changes to Github!

One problem that it may be worth mentioning at the top here: When you're ready to commit changes to your code, do not commit everything at once with git commit . or git commit -a. Use git status to see which files have been edited, then use git diff <path-to-file> to make sure that the only changes there are changes you intended to make. Then you can use git add <path-to-file> to add that file for committing.

This is particularly important because you do not want to commit your local changes to the docker-compose.yml, since that will post our API keys publicly, which means that we will need to regenerate the API key and everyone on the team will need to update their keys. When you run git status you will also often see files in the .ivy2/cache directory that have edits. You never want to commit those files (and the edits are usually just timestamps automatically being changed). It isn't dangerous to edit them, it just clogs up the git history :)

In addition, before creating a PR (as well as before you ask for another review after making changes to a PR), pull the most recent changes from the develop branch into your branch using git pull origin develop. You should then test again using this most recent code from the develop branch to make sure that your changes still work!

Use 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). This is why you start with git checkout develop before running git checkout -b <branch-name>.

Issue Branch Naming Conventions

To name your branch, follow this convention:

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

E.g. if you are implementing a fix for this issue: https://github.com/ProjectSidewalk/SidewalkWebpage/issues/474, you might name your branch474-admin-update-activities-table. Please refrain from including the '#' sign at the beginning of the branch name, because that can mess up command line autocomplete :)

Notes on Writing and Testing Code

Does your code add or change any text that users see on the site?

If so, then you will need to add in temporary translations into Spanish, Dutch, and Mandarin. You can use Google Translate for this. Mikey will compile a list of all the temporary translations that we make using Google Translate and will occasionally send that list to our partners that provide official translations. Below is how to add new translations:

• If you are adding text in a .scala.html file, add a line to each of the conf/messages.en/es/nl/zh files with the translations, and reference those in the HTML file using @Messages("your.translation.id").
• If you are adding text in a JavaScript file, add the translations to the appropriate files in public/locales and reference them in the JavaScript using i18next.t('your-translation-id').

Are you making changes to the Validate page?

If so, you will want to test on mobile as well; our mobile site shows only the Validate and sign in/up pages Here is how to test out the mobile website:

1. Start by testing using Google Chrome's dev tools. You can see some quick instructions for how to open those here.
2. If things look good in Chrome's dev tools, you should then test on your own mobile device if possible (the emulator is far from perfect). To test on your mobile device, find you IP address using ipconfig or ifconfig in your terminal. Then go to <ip_address>:9000 on your mobile device instead of localhost:9000. Some caveats:
   • Your computer and phone need to be on the same wifi network for this to work
   • This often doesn't work at coffee shops and the like. Presumably they have some security measures in place to prevent this.
   • Tools like ipconfig and ifconfig can sometimes show you multiple different IP addresses. Make sure to try all of them to find the right one!

Do you need to login as an admin user?

If so, you can create an admin account in your local dev environment relatively easily by changing the "role" for an account in the database to "Administrator". Steps below:

1. Create an account on your local environment if you haven't already.
2. Open your database in a database manager like Valentina Studio (instructions on that here). Or you can work fully command line by running make ssh target=db in the root project directory, followed by psql -U sidewalk -d <your-database-name>.
3. Find your user_id in the database. You can do this visually by looking at entries in the sidewalk_user table, or by running the query SELECT user_id FROM sidewalk_user WHERE username = '<your-username>';.
4. Update your role in the user_role table from 1 (Registered) to 4 (Administrator). Again, you can do this visually by looking through the user_role table and updating the entry, or by running the query UPDATE user_role SET role_id = 4 WHERE user_id = '<your-user-id>';.

Do expect the code you wrote to look/work differently for different types of users?

If so, you should test the site for those different types of users! Instructions on how log in as each type of user below:

• Anonymous user: You are given an anon account by default when visiting the site for the first time. The easiest way to test like this is to open a new incognito/private browser window, which should give you a fresh anon account (you should see the "Sign in" button in the navbar, not a username).
• Registered user: Simply create an account and login via the "Sign in" button in the top right of the page.
• Administrator: Instructions in the section above this one!
• Amazon Mechanical ("MTurk") Turk user ("Turker"): 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 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.

Steps for Submitting PRs

1. 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 one last time using this updated code, push that merge commit to your branch on Github, then create the PR.
2. When you submit a pull-request, it will be reviewed before we merge it with the develop branch (and consequently to master branch). Write descriptive titles and follow the provided template.

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.