Home
Combine using creativity and software development industry standards to build incredible user/customer experiences when accessing the VA Diffusion Marketplace
We have each other’s backs. There is always time to help one-another.
DO:
- Ask questions
- Get guidance
- Reach out for help
- Be creative (in a reasonable way :))
- Check in often
- Fail fast
- Help each other
DO NOT:
- Have radio silence
- Have nothing to do (there is always something to do)
- Commitment
- Integrity
- Initiative
- Fun
- Resilience
https://github.com/agilesix/diffusion-marketplace
- We squash and merge
- Delete branch after merging
We use USWDS 2.0: https://v2.designsystem.digital.gov/utilities/ Use the utilities classes to quickly build out a page
https://circleci.com/gh/agilesix/diffusion-marketplace
- If you break it, you fix it!
- But seriously, the team will help you fix it if needed.
Note: for any language - readability/fancy syntax. In other words, please be sure your code is readable before thinking about any fancy syntax, or heavily comment the code
- Comment in code for clarity
- Write method documentation if necessary
- default to yes, it needs documentation
- An example of documentation for methods
/* @param waitTimes (object) - an object with a list of keys of facility services names in camelCase as keys with a value of an object
* @param service (string) - a health service taxonomy such as "Primary Care"
* @param established (boolean - default = false) - which object value is desired. two choices: 'new' or 'established'. true gives 'established' value. false gives 'new' value.
* returns a string formatted with the number of days for appointment wait times ex. '8 days'
*/
appointmentWaitTime(waitTimes, service, established = false) {
// convert service to camel case
const serviceKey = _.camelCase(service);
// find service in waitTimes object as a key
const time = waitTimes[serviceKey];
// return waitTimes for service
return time ? `${time[established ? 'established' : 'new']} days` : '';
}
- Does it need a unit test?
- yes
- Always double quote attributes
- Alphabetical properties
- Try to keep three levels of nesting at max
- ES6 syntax
- Semi-colons? yes;
- No coffee script
- If there is an asset associated with the rake task, put in
lib/assetsfolder
- Merge early and often
- Use story number for branching, all lower case
- Ex.
dm-210
- Ex.
- Commit early and often
- Try to commit at the end of the day, always push that branch
- This is so another developer can pick up the task
- Commit messaging format
<story-number>: <what was done>- Ex. DM-406: placed button in the right place
- Would also be nice to put the task number in the commit message
<story-number>: [<task-number>] <what was done>- Ex. DM-406: [DM-409] removed dead code
- Title:
<story-number>: <story title> or <story-number>: [<task-number>] <task description>- Ex. DM-406: Implement new Practice Page
- Ex. DM-406: [DM-409] Add sticky nav to practice page
- If doing a task that is not part of a story, use the following format:
DM-000: <the task description>
- Description:
### JIRA issue link
## Description - what does this code do?
## Testing done - how did you test it/steps on how can another person can test it
## Screenshots, Gifs, Videos from application (if applicable)
## Link to mock-ups/mock ups (image file if you have it) (if applicable)
## Acceptance criteria
- [ ]
## Definition of done
- [ ] Unit tests written (if applicable)
- [ ] e2e/accessibility tests written (if applicable)
- [ ] Events are logged appropriately
- [ ] Documentation has been updated, if applicable
- [ ] A link has been provided to the originating JIRA issue
- [ ] No sensitive information (i.e. PII/credentials/internal URLs/etc.) is captured in logging, hardcoded, or specs
- Request a reviewer or two
- Reviewer(s) pulls down code to both test and code review
