Volunteer flows

This page contains step-by-step workflows for volunteers. Not a volunteer? Join us:

Sign up to volunteer

Interview building and maintenance

Register a developer account on the LIT Lab development server

1. Register an account on the development server. This will be a regular user account.
2. You will need developer privileges, so email us to request developer privileges. Include the email address you registered with and the reason you need developer privileges (i.e., "I'm a Document Assembly Line volunteer.").
3. If your request is granted, you will need to log out and back in before you can access the Playground

Go to the Playground

Set up and configure GitHub

1. If you already have a GitHub account, log in. If not, create one.
2. If you want to keep your email address private, visit your email settings and turn on the Keep my email addresses private option
3. Go to your GitHub integration page and authorize your GitHub account
4. After you complete the interview builder training and final project, ask an organizer to add you to the DAL volunteers team on GitHub

Complete your first issue and pull request

After you complete the interview builder training and final project, you are ready for your first issue! (An issue is an update, bug, enhancement, or other coding task.)

When you are first starting to work on Docassemble interviews, it can be hard to judge the level of difficulty of an issue. We identify good issues for new builders with the starter label in GitHub. Sometimes we misjudge, so if you end up with an issue that seems above your skill level, check in with us.

To get started on your first issue:

1. Pick a starter issue. You can visit the Interview updates project board or search starter issues in our GitHub repositories (the project board may be missing some starter issues).
2. Is the issue a typo?
   • If it is, continue
   • If not, decide whether it is a good match for your level of experience. If you aren't sure, ask a more experienced member of the Builder crew. (Michelle is great resource for this!)
3. Check to see if the issue is still up to date. Sometimes issues are fixed but not closed, or have become irrelevant for some other reason. If the issue should be closed, write a comment about why it can be closed and close it. Look for a different issue.
4. Assign yourself to the issue and start working on it
5. Follow the GitHub workflow (also described in training session 3)
   • When you commit your code, commit to a new branch
   • Commit messages should be a reminder of what you did
   • When creating a pull request, the comment should:
     1. Reference your issue(s) (e.g., Closes #42) so they will be closed when the pull request is merged
     2. Describe the changes you made in your code and why
   • Request a review from @SuffolkLITLab/dal-reviewers for your pull request