Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Process and Style Guide #9

Open
sylv1ah opened this issue Jun 4, 2019 · 1 comment
Open

Process and Style Guide #9

sylv1ah opened this issue Jun 4, 2019 · 1 comment
Labels
documentation Improvements or additions to documentation

Comments

@sylv1ah
Copy link
Collaborator

sylv1ah commented Jun 4, 2019

Process Guide

Daily Schedule:

10am : Start
10:15 - 10:30 : Standup
10:30 - 11:45 : Build
11:45 - 12:00 : Break + Check ups
12:00 - 1:00 : Build
LUNCH
2:00 - 3:30 : Build + Swap pairs
3:30 - 3:45 : Break + Check up
3:45 - 5:00 : Build
5:00 - 5:15: Break (Or finish if theres a scheduled speaker)
5:15 - 6:00: Build

Branches:

We will be working off master for the first sprint, then will discuss on working of a staging branch for the second sprint

Branch names:

  • feature/name-of-feature
  • fix/issue# or fix/name-of-fix

Commits and commit messages:

To be written in present tense explaining what the commit does. Each commit should aim to only address one action.

Naming Structure:

Functions - camelCase, describe what it does
Classes - Block Element Modifier (BEM)

Tests - [filename].test.js
Routes - if more than one word, dash between words

Asynchronicity:

Whenever possible, use promises over callbacks.

Styling:

For styling we will be using styled-components
https://www.styled-components.com/docs
component file name:

  • button.js

styled-components file name:

  • button.styled.js

Opening pull requests:

Follow the checklist below.
Create the PR and assign the other pair (who haven't worked on the code) as reviewers.
Relate the issue number either in the commit message or pull request message.

Merging pull requests:

Check through the code carefully, comment on anything questionable by hovering over the line and clicking the blue plus that appears.

If changes need to be made, add the changes-needed label.
If everything is a-okay, merge the pull request and delete the branch.

Accessibility:

Avoid divs in favour of semantic elements (eg section, header, button) wherever possible.
All form elements should have labels.
Use Aria roles as a last resort.

(Process guide inspired by @jokosanyang ✨)

Style Guide

Figma

https://www.figma.com/file/IV6lJc5K9AlAhFYehxRk11c0/RE4.W?node-id=0%3A1


Colours

Colour To be used for
#000000 header, back and tick buttons, selected filters
#000000 splash and landing page logo, other buttons
#000000 logo in header?
#000000 backgrounds
#000000 text

Typography

Typeface: Bangers
https://fonts.google.com/specimen/Bangers

Use em/rem instead of px!

Tag Sample
h1: splash, landing 96px / 6em
h2: headers 32px / 2em
p: text buttons 24px / 1.5em
p: placeholders, links, body text 16px / 1em

Space and sizing

Choose your sizes from this set of values:

@sylv1ah sylv1ah pinned this issue Jun 4, 2019
@sylv1ah sylv1ah added the documentation Improvements or additions to documentation label Jun 6, 2019
@Fweddi Fweddi changed the title Process Guide Process and Style Guide Jun 7, 2019
@starsuit
Copy link
Collaborator

Branch names:

  • feature/name-of-feature
  • fix/issue# or fix/name-of-fix

I quite like the idea of having branch categories, e.g.
feature/components/button
feature/tests/button-test

anyone hate that?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
None yet
Development

No branches or pull requests

2 participants