diff --git a/.dockerignore b/.dockerignore new file mode 100644 index 00000000..e69de29b diff --git a/.env.dev b/.env.dev deleted file mode 100644 index ca9948ba..00000000 --- a/.env.dev +++ /dev/null @@ -1,9 +0,0 @@ -DEBUG=1 -SECRET_KEY=!0^+)=t*ly6ycprf9@kfw$6fsjd0xoh#pa*2erx1m*lp5k9ko7 -DJANGO_ALLOWED_HOSTS=localhost 127.0.0.1 [::1] -DB_ENGINE=django.db.backends.postgresql -DB_NAME=activity_dev -DB_USER=activity -DB_PASSWORD=activity -DB_HOST=db -DB_PORT=5432 \ No newline at end of file diff --git a/.env.dev.example b/.env.dev.example new file mode 100644 index 00000000..fce751db --- /dev/null +++ b/.env.dev.example @@ -0,0 +1,9 @@ +DEBUG=1 +SECRET_KEY= +DJANGO_ALLOWED_HOSTS= +DB_ENGINE= +DB_NAME= +DB_USER= +DB_PASSWORD= +DB_HOST= +DB_PORT= diff --git a/.env.docker-compose b/.env.docker-compose new file mode 100644 index 00000000..b69dc41a --- /dev/null +++ b/.env.docker-compose @@ -0,0 +1,16 @@ +DEBUG=1 +SECRET_KEY=secretkey123 +DJANGO_ALLOWED_HOSTS=* +DB_ENGINE=django.db.backends.postgresql +DB_NAME=activity_dev +DB_USER=activity +DB_PASSWORD=activity +DB_HOST=db +DB_PORT=5432 + +ACTIVITY_CE_DB_ENGINE=django.db.backends.postgresql +ACTIVITY_CE_DB_NAME=activity_dev +ACTIVITY_CE_DB_USER=activity +ACTIVITY_CE_DB_PASSWORD=activity +ACTIVITY_CE_DB_HOST=db +ACTIVITY_CE_DB_PORT=5432 \ No newline at end of file diff --git a/.github/workflows/activity_ci_cd.yml b/.github/workflows/activity_ci_cd.yml index 2a4b1e78..f3cf205c 100644 --- a/.github/workflows/activity_ci_cd.yml +++ b/.github/workflows/activity_ci_cd.yml @@ -1,46 +1,41 @@ name: Activity -on: +on: push: - branches: - - dev - - staging + branches: + - develop pull_request: - branches: - - dev - - staging + branches: + - develop + paths-ignore: + - 'docs/**' + - '*.md' release: types: - - created + - published jobs: - Build_and_test: + Build_lint_test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v1 - - name: Set up Python 3.7 + - name: Set up Python 3.8 uses: actions/setup-python@v1 with: - python-version: 3.7 - - name: Install dependencies - run: | - sudo apt-get update -y - sudo apt-get install gdal-bin - python -m pip install --upgrade pip - pip install pipenv + python-version: 3.8 - name: Lint with flake8 run: | pip install flake8 # stop the build if there are Python syntax errors or undefined names - flake8 . --count --select=E9,F63,F7,F82 --show-source --statistics + flake8 . --count --select=E9,F63,F7,F82 --show-source --statistics # TODO use a main flake8 config file # exit-zero treats all errors as warnings. The GitHub editor is 127 chars wide flake8 . --count --exit-zero --max-complexity=10 --max-line-length=127 --statistics - name: Run Tests - env: + env: CODECOV_TOKEN: ${{ secrets.CODECOV_TOKEN }} run: | - pipenv install - source $(python3 -m pipenv --venv)/bin/activate + cp activity/settings/local-sample.py activity/settings/local.py + pip install pip-tools && pip-sync coverage run manage.py test echo "++++++++ Show test coverage report +++++++" coverage report @@ -48,8 +43,9 @@ jobs: bash <(curl -s https://codecov.io/bash) Infrastructure: - runs-on: ubuntu-latest - needs: Build_and_test + runs-on: ubuntu-latest + needs: Build_lint_test + if: github.ref == 'refs/heads/develop' || github.event_name == 'release' steps: - uses: actions/checkout@v1 - name: Setup terraform @@ -61,7 +57,7 @@ jobs: terraform version - name: Run infrastructure script - env: + env: BACKEND_BUCKET_DEV_ENV: ${{ secrets.BACKEND_BUCKET_DEV_ENV }} STATE_FILE_DEV_ENV: ${{ secrets.STATE_FILE_DEV_ENV }} SPACES_ACCESS_KEY: ${{ secrets.SPACES_ACCESS_KEY }} @@ -75,13 +71,8 @@ jobs: SERVICE_ACCESS_TOKEN: ${{ secrets.SERVICE_ACCESS_TOKEN }} DB_SIZE: ${{ secrets.DB_SIZE }} PG_VERSION: ${{ secrets.PG_VERSION }} + PROJECT_NAME: $$ {{ secrets.PROJECT_NAME }} DB_NAME_DEV_ENV: ${{ secrets.DB_NAME_DEV_ENV }} - # staging vars, some are reused from dev_env - BACKEND_BUCKET_STAGING: ${{ secrets.BACKEND_BUCKET_STAGING }} - STATE_FILE_STAGING: ${{ secrets.STATE_FILE_STAGING }} - CLUSTER_NAME_STAGING: ${{ secrets.CLUSTER_NAME_STAGING }} - K8S_VERSION_STAGING: ${{ secrets.K8S_VERSION_STAGING }} - DB_NAME_STAGING: ${{ secrets.DB_NAME_STAGING }} # Prod vars BACKEND_BUCKET_PROD: ${{ secrets.BACKEND_BUCKET_PROD }} STATE_FILE_PROD: ${{ secrets.STATE_FILE_PROD }} @@ -89,15 +80,15 @@ jobs: K8S_VERSION_PROD: ${{ secrets.K8S_VERSION_PROD }} DB_NAME_PROD: ${{ secrets.DB_NAME_PROD }} run: | - export TRAVIS_EVENT_TYPE="push" chmod +x ci-scripts/create_infrastructure.sh bash ./ci-scripts/create_infrastructure.sh Build_and_push_image: - runs-on: ubuntu-latest + runs-on: ubuntu-latest needs: Infrastructure + if: github.ref == 'refs/heads/develop' || github.event_name == 'release' steps: - - uses: actions/checkout@v1 + - uses: actions/checkout@v1 - name: Setup docker-ce run: | sudo apt install apt-transport-https ca-certificates curl software-properties-common @@ -105,11 +96,14 @@ jobs: sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu bionic stable" sudo apt install docker-ce sudo docker version - + - name: Build and Push env: + TAG_NAME: ${{ github.event.release.tag_name }} DOCKER_HUB_USERNM: ${{ secrets.DOCKER_HUB_USERNM }} DOCKER_HUB_PASSWD: ${{ secrets.DOCKER_HUB_PASSWD }} + DOCKER_HUB_USERNAME: ${{ secrets.DOCKER_HUB_USERNAME }} + DOCKER_HUB_PASSWORD: ${{ secrets.DOCKER_HUB_PASSWORD }} ACTIVITY_CE_DB_NAME_DEV: ${{ secrets.ACTIVITY_CE_DB_NAME_DEV }} ACTIVITY_CE_DB_USER_DEV: ${{ secrets.ACTIVITY_CE_DB_USER_DEV }} ACTIVITY_CE_DB_PASSWORD_DEV: ${{ secrets.ACTIVITY_CE_DB_PASSWORD_DEV }} @@ -127,9 +121,7 @@ jobs: GOOGLE_MAP_API_KEY: ${{ secrets.GOOGLE_MAP_API_KEY }} APPLICATION_NAME: ${{ secrets.APPLICATION_NAME }} REGISTRY_OWNER: ${{ secrets.REGISTRY_OWNER }} - # staging variables. others are reused from dev - ACTIVITY_CE_DB_NAME_STAGING: ${{ secrets.ACTIVITY_CE_DB_NAME_STAGING }} - APPLICATION_ENV_STAGING: ${{ secrets.APPLICATION_ENV_STAGING }} + APPLICATION_NAME_DEV: ${{ secrets.APPLICATION_NAME_DEV }} # Production Vars APPLICATION_ENV_PROD: ${{ secrets.APPLICATION_ENV_PROD }} ACTIVITY_CE_DB_NAME_PROD: ${{ secrets.ACTIVITY_CE_DB_NAME_PROD }} @@ -138,16 +130,15 @@ jobs: ACTIVITY_CE_DB_HOST_PROD: ${{ secrets.ACTIVITY_CE_DB_HOST_PROD }} ACTIVITY_CE_DB_PORT_PROD: ${{ secrets.ACTIVITY_CE_DB_PORT_PROD }} run: | - export TRAVIS_COMMIT=$GITHUB_SHA - export TRAVIS_EVENT_TYPE="push" chmod +x ci-scripts/build_docker_image.sh bash ./ci-scripts/build_docker_image.sh Deploy: needs: Build_and_push_image runs-on: ubuntu-latest + if: github.event_name == 'release' container: - image: yagami22/ci-deploy-image + image: yagami22/ci-deploy-image steps: - uses: actions/checkout@v1 - name: Deploy to DO @@ -157,25 +148,27 @@ jobs: SERVICE_ACCESS_TOKEN: ${{ secrets.SERVICE_ACCESS_TOKEN }} DOCKER_HUB_USERNM: ${{ secrets.DOCKER_HUB_USERNM }} DOCKER_HUB_PASSWD: ${{ secrets.DOCKER_HUB_PASSWD }} + DOCKER_HUB_USERNAME: ${{ secrets.DOCKER_HUB_USERNAME }} + DOCKER_HUB_PASSWORD: ${{ secrets.DOCKER_HUB_PASSWORD }} B64_TOKEN: ${{ secrets.B64_TOKEN }} DEFAULT_NOTIFY: ${{ secrets.DEFAULT_NOTIFY }} RATE_LIMIT: ${{ secrets.RATE_LIMIT }} - HOST_DOMAIN: ${{ secrets.HOST_DOMAIN }} APPLICATION_NAME: ${{ secrets.APPLICATION_NAME }} REGISTRY_OWNER: ${{ secrets.REGISTRY_OWNER }} - # staging variables - CLUSTER_NAME_STAGING: ${{ secrets.CLUSTER_NAME_STAGING }} - HOST_DOMAIN_STAGING: ${{ secrets.HOST_DOMAIN_STAGING }} - APPLICATION_ENV_STAGING: ${{ secrets.APPLICATION_ENV_STAGING }} + MIN_PODS: ${{ secrets.MIN_PODS }} + MAX_PODS: ${{ secrets.MAX_PODS }} + APPLICATION_NAME_DEV: ${{ secrets.APPLICATION_NAME_DEV }} + MIN_PODS_DEV: ${{ secrets.MIN_PODS_DEV }} + HOST_DOMAIN_DEV: ${{ secrets.HOST_DOMAIN_DEV }} SLACK_CHANNEL_HOOK: ${{ secrets.SLACK_CHANNEL_HOOK }} # Production Vars APPLICATION_ENV_PROD: ${{ secrets.APPLICATION_ENV_PROD }} CLUSTER_NAME_PROD: ${{ secrets.CLUSTER_NAME_PROD }} HOST_DOMAIN_PROD: ${{ secrets.HOST_DOMAIN_PROD }} + MIN_PODS_PROD: ${{ secrets.MIN_PODS_PROD }} + APPLICATION_NAME_PROD: ${{ secrets.APPLICATION_NAME_PROD }} run: | - export TRAVIS_COMMIT=$GITHUB_SHA export FILE_PATH="/github/home/.docker/config.json" - export TRAVIS_EVENT_TYPE="push" chmod +x ci-scripts/deployment.sh bash ./ci-scripts/deployment.sh if [[ $? -eq 0 ]]; then diff --git a/.gitignore b/.gitignore index 02021186..1c4d698c 100644 --- a/.gitignore +++ b/.gitignore @@ -88,7 +88,12 @@ local.py production.py .env +.env.dev +.venv +.env.dev db.sqlite3 .idea/ .vscode .history/ + +assets/ diff --git a/.travis.yml b/.travis.yml deleted file mode 100644 index 3f03a586..00000000 --- a/.travis.yml +++ /dev/null @@ -1,49 +0,0 @@ -# Language used usually but in or case we wish to not run -# the default pip install command hence just setting the -# language to minimal will work. -language: minimal - -notifications: - slack: - if: branch = dev OR branch = staging - on_pull_requests: false - secure: OzJ+zoqdrsgO0Fx2cfat1EyfcqwkBi5WJ9zRr5cEZxb6Y3mlkiURuzE1jgLyvOwzJln0H+eWNlUZ6sy9ijpoEdKDJtAftkOkbQuk1WWG+kzbZ2zhMxKP32B0Cemy44VP3aHljPmzQQN58Pfl+IO1GbxGSaGN/DUPW8NXdKC7+I3RlGHoh0pVoqsnJgNKzf2G9uAfVMujs7Mhc9n6qoUNFp8kRHgphOAEP0+B5ioG6/lei2WKhEPzn582ElHODFSfyg/TSzH4lFHAudgZQ6roA5b4CQRfUUg1hLC4m9NBBTFBMXk1IACWt1rBp9ufgKRrRCVs1n1w9JSITXB5c6cmONQuv6IgjIuJuqd+bH9sqxl5Hd/FBemkNXS5jcQ+IgGiO8sMGgvZ+ZCb1rgQdUH6vUykOgHpiIgfDbOXQf5uE/o7yiSVKh/QncbRZ96pStV2HR5KOyYK7d27UBmtRnA9GtNK0EAw+GpQfu4/jn6gaBpSoArpbLpKt8NksYfDcpyo//xLCrxN0u8VdLdayCXcJ2OaFw9imd5NDB55GV4BfxG3JOQnUNA1pAdSZWPmvb8COTfHPeAxyU24qGgURU0xLppCkz3QybSjIjtR55bLAuoqhfKEBsaJhWoYQP6XEG8/eZm18swqZQG4QEVEOEWkPLnxwRPjk9KkJiPYphlCkdI= -jobs: - include: - #@--- Stage to run tests ---@# - - state: Build_and_test - name: "Tests Stage" - sudo: required - - script: - - chmod +x ci-scripts/run_tests.sh - - ./ci-scripts/run_tests.sh - - #@--- Stage to create the infrastructure ---@# - - stage: Infrastructure - name: "Setup_Infrastructure" - - script: - - export VER="0.12.21" - - wget https://releases.hashicorp.com/terraform/${VER}/terraform_${VER}_linux_amd64.zip - - unzip terraform_${VER}_linux_amd64.zip - - sudo mv terraform /usr/local/bin/ - - chmod +x ci-scripts/create_infrastructure.sh && ./ci-scripts/create_infrastructure.sh - - #@--- Stage to build and push image ---@# - - stage: Build docker Image - services: - - docker - name: "Build image" - - script: - - chmod +x ci-scripts/build_docker_image.sh - - ./ci-scripts/build_docker_image.sh - - #@--- Stage to deploy application ---@# - - stage: Deploy - services: - - docker - name: "Deploy to DO" - sudo: required - - script: - - export FILE_PATH="/home/travis/.docker/config.json" - - chmod +x ci-scripts/deployment.sh - - ./ci-scripts/deployment.sh diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md index 4cdcd7b6..53d6b638 100644 --- a/CODE_OF_CONDUCT.md +++ b/CODE_OF_CONDUCT.md @@ -55,7 +55,7 @@ further defined and clarified by project maintainers. ## Enforcement Instances of abusive, harassing, or otherwise unacceptable behavior may be -reported by contacting hello@hikaya.io. All +reported by contacting support@hikaya.io. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index ba824ffb..85c95da9 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,23 +1,44 @@ +_UPDATED: 20200502_ + # Contributing to Hikaya -Thanks for checking out Activity. Activity is an open source project currently maintained by the team at [Hikaya](https://hikaya.io/team). +Thanks for checking out **Activity**. Activity is an open source project currently maintained by the team at [Hikaya](https://hikaya.io/team). -# Table of Contents +## Table of Contents - [Contributing to Hikaya](#contributing-to-hikaya) - [Table of Contents](#table-of-contents) - - [Ground rules & expectations](#ground-rules--expectations) + - [Ground rules and expectations](#ground-rules-and-expectations) - [How to contribute](#how-to-contribute) - - [Our development process](#our-development-process) - - [Contribution review process](#contribution-review-process) - - [Coding Conventions](#coding-conventions) - - [Github Labels](#github-labels) - - [Naming conventions](#naming-conventions) - - [Code standards](#code-standards) - - [CI/CD](#cicd) - - [Community](#community) - -# Ground rules & expectations + - [Contribution review process](#contribution-review-process) + - [For long-term contributors](#for-long-term-contributors) + - [Tips on how to best engage and contribute](#tips-on-how-to-best-engage-and-contribute) + - [Role of Maintainers](#role-of-maintainers) + - [Community](#community) + - [Development Process](#development-process) + - [Roadmap](#roadmap) + - [How we work](#how-we-work) + - [Planning](#planning) + - [Bug report](#bug-report) + - [Feature request](#feature-request) + - [Definition of done](#definition-of-done) + - [Navigating our repos](#navigating-our-repos) + - [Labels](#labels) + - [Milestones](#milestones) + - [Task board](#task-board) + - [Triage](#triage) + - [Hardening sprint](#hardening-sprint) + - [QA testing](#qa-testing) + - [How we manage our code](#how-we-manage-our-code) + - [Commits](#commits) + - [Pull Requests](#pull-requests) + - [Deployments](#deployments) + - [Coding Conventions](#coding-conventions) + - [Naming conventions](#naming-conventions) + - [Code standards](#code-standards) + + +## Ground rules and expectations Before we get started, here are a few things we expect from you (and that you should expect from others): @@ -26,47 +47,253 @@ Before we get started, here are a few things we expect from you (and that you sh - If you open a pull request, please ensure that your contribution passes all tests. If there are test failures, you will need to address them before we can merge your contribution. - When adding content, please consider if it is widely valuable. Please don't add references or links to things you or your employer have created as others will do so if they appreciate it. -# How to contribute +## How to contribute All contributors are welcome to submit issues and make pull requests to the repository. - - Look through the [issues](https://github.com/hikaya/activity/issues). +- Look through the [issues](https://github.com/hikaya-io/activity/issues?q=is%3Aopen+is%3Aissue+no%3Aassignee+-label%3AEpic). -If you'd like to contribute, start by searching through the [issues](https://github.com/hikaya/activity/issues) and [pull requests](https://github.com/hikaya/activity/pulls) to see whether someone else has raised a similar idea or question. If you see none, feel free to reach out to us on [Spectrum]("https://spectrum.chat/hikaya) +If you'd like to contribute, start by searching through the [issues](https://github.com/hikaya/activity/issues) and [pull requests](https://github.com/hikaya/activity/pulls) to see whether someone else has raised a similar idea or question. If you see none, feel free create an issue and ask for guidance on where to start. + +- If you find an issue you would like to work on, feel free to assign it to yourself. +- If you don't find one you would like to work on, create an issue, assign a label and @mention one of the maintainers to let them know about the issue. + +### Contribution review process + +This repo is currently maintained by Hikaya, who have commit access. They will likely review your contribution. If you haven't heard from anyone in 5 days, feel free to bump the thread or @-mention a maintainer to review your contribution. - - If you find an issue you would like to work on, feel free to assign it to yourself. - - If you don't find one you would like to work on, create an issue, assign a label and @mention one of the maintainers to let them know about the issue. +### For long-term contributors - ## For contributors who want to support this project in the long term Long standing contributors will be given `write` access to the repository. In addition, we have slots for contributors to be given `maintainer` status which allows contributors to administer the repository, support the onboarding of new contributors, and influence the product roadmap. Our current maintainers are: Peter Odeny ([@odenypeter](https://github.com/odenypeter)) and Isaac Kimaiyo ([@Kimaiyo077](https://github.com/kimaiyo077)). + +### Tips on how to best engage and contribute + +1. **Determine how many hours you can commit to each week.** Think about how many hours you can commit to each week. Currently many of our contributors spend around ~20-25 hours a week but there is no minimum, only that you set your own hours. +2. **Come up with your own weekly schedule and propose it to the team.** If you have certain days and times you are tentatively available you can put together a schedule of what a typical week will look like so others can try and sync with you or know when to reach out on slack. These are just tentative and used by other contributors to coordinate calls between each other. +3. **Try to make at least one of the sprint calls each week (Monday and Saturday 7 PM EAT).** If you can’t make a call, kindly write on the #sprint-planning slack channel or message me before hand so we can know if you are able to join or not. We just ask for communication courtesy but understand contributors won’t be able to make each call. +4. **Ask for help when you need it** Our philosophy is to let contributors work on anything they think could add value to our apps. The core team at Hikaya will try to make themselves available to support any new onboarding or even have paired programming sessions on an issue to help you get started. We kindly ask all contributors to not be shy and ask for help when you need it. +5. **Be open and communicate** If life has gotten busy or priorities have changed and you can no longer contribute, no worries, we completely understand! All we ask is for you to communicate and let us know upfront so we can plan accordingly. You're always welcome to pause and contribute another time. + +### Role of Maintainers + +- Set priorities for each sprint in coordination with the product and technical leads. +- Maintain and ensure consistent and proper use of the sprint board. +- Be a reviewer for many tasks. Clear communication will be done at the beginning of the sprint around which tasks will be reviewed by whom. +- “Coach” other members as they work on their tasks. + +### Community -# Our development process +Discussions about Activity take place in the `Issues` sections for each repo, as well as on [Spectrum](https://spectrum.chat/hikaya). Anybody is welcome to join these conversations. +Thanks for contributing! + +--- + +# Development Process + +## Roadmap + +The team has a 6-12 month high-level product roadmaps ([See Activity Roadmap](https://team.hikaya.io/start/activity-roadmap.html)) which defines epics and feature sets to be addressed during this period. + +## How we work + +We will work in two-week **Sprints** on the items on the roadmap. At the end of each sprint, we want to have a stable release of **Activity** that can be shipped to our users. The work planned during a sprint is captured in the Task board. The feature sets of each sprint are highlighted in a published [**Release**](https://github.com/hikaya-io/activity/releases) in Github. + +**A typical month** + +> **Week 1**: Reduce debt introduced in the previous iteration, address critical issues uncovered in the previous iteration, and plan the next iteration. + +> **Week 2**: Work according to the milestone and minor release to `production`. + +> **Week 3+**: Work according to the milestone and +monitoring the minor release and fix critical issues. + +> **Final Week**: See `Hardening Sprint`. The team improves test coverage by building tests and cleaning up unused code and templates. Deploy to `production` and showcase new features. + +We follow a typical checklist before we ship new features:
+✅Pull Requests are reviewed and merged to `develop` branch.
+✅The PR is deployed to `development` environment and passes user acceptance testing (UAT).
+✅Manually execute the Smoke Test on all supported platforms.
+✅Release notes updated.
+✅Deploy to `production`.
+ +## Planning + +Before each Milestone, we will prioritize features to implement and bugs to fix in the upcoming iteration. `Bugs` and `Defects` are assigned to a sprint for the iteration and include steps to reproduce and `current and expected behaviors`. For new features, we create `Tasks` and include `Acceptance Criteria`. + +We use the following definitions to track our issues: +* **Bug**: An issue that stop the user from doing what they intended. +* **Defect**: An issue that does not do what it was intended to do. +* **Task**: An issue that is an enhancement or new feature. + +### Bug Report + +> **Current behavior**
+_A clear and concise description of what the bug is._ + +> **Expected behavior**
+_A clear and concise description of what you expected to happen._ + +> **To Reproduce:** +``` +Steps to reproduce the behavior: +1. Go to '...' +2. Click on '....' +3. Scroll down to '....' +4. See error +``` + +>**Screenshots**
+_If applicable, add screenshots to help explain your problem._ + +### Feature Request + +> **Is your feature request related to a problem? Please describe.**
+_A clear and concise description of what the problem is._ + +> **Acceptance Criteria**
+_A clear and concise description of how to ensure the feature request is met._ + +``` +GIVEN I am a logged in user + +AND I navigate to the main page... + +AND I click on the button. + +THEN I expect this to happen.. +``` +> **Additional context**
+_Add any other context or screenshots about the feature requests._ + +### Definition of Done +Each issue card will have an **Acceptance Criteria** that defines the definition of done for every task that is worked on. + +--- + +## Navigating our repos + +### Labels + +We use **Github Labels* to describe the task card including its priority and complexity. Here is a list that we try to consistently use across all our applications: + +|Label|Description| +|--|--| +|`Good first issue`|Good for newcomers| +|`bug`|Something isn't working| +|`defect`| Something isn't working right| +|`enhancement`|New feature| +|`dependencies`|Updates dependencies| +|`duplicate`|Issue or pull request exists| +|`help wanted`|Extra attention is required| +|`requires research`|Further information is required| +|`priority`|High priority issue| +|`design needed`|Requires a wireframe| +|`tests`|For unit and integration tests| +|`0`|Insignificant task (minimal effort and time needed)| +|`1`|Simple issues requiring minimal effort| +|`2`|Not so complex, requiring a relatively good amount of effort and time to fix| +|`5`|Complex task| +|`8`|Very complex task| + +> **Story point estimation**
+> Story points are used to estimate the effort needed for each task. We try to avoid using time estimates and a more useful measurement for team capacity is the effort needed and then complexity of a task. + +| Story Point | Complexity reference | +|--|--| +| 1 | Changing a label | +| 2 | Making a model change | +| 3 | Implementing CRUD on the UI | +| 5 | Implementing a new model| +| 8 | Introducing complex logic| +| 13| Research task, building a proof of concept | +| 21| Should be used sparingly| + +## Milestones + +We work toward a **Sprint** with the goal to release to `production` every two weeks. We use **Github Milestones** to track what issues contributors work on during a specific Sprint. Each milestone will have a start and end date and the product team will help to groom the issues and tag them to a specific sprint number before the sprint starts. + +Each week we have two calls as a team to discuss our priorities and reflect: +* **Sprint Planning:** every Monday 7 PM EAT +* **Sprint Review:** every Saturday 7 PM EAT + +> Join calls using `Google Meet` and follow the `#sprint-planning channel` on slack. + +## Task Board +We use **Github Projects** to manage our current sprints with automated workflows. Each repo will have its own task board to manage issues and will consist of the following columns: +- `To do` +- `In progress` +- `Pull request` +- `Dev testing` +- `Done` + +Before every sprint, we archived all issues in the `Done` columns and add issue cards with the current sprint milestone tagged to them. During our sprint calls, the team will groom, discuss, and assign cards to contributors to work on. + +> **Note:** +> * At the beginning of every milestone, we include all items in the `To do` stage and move them over as we go.  +> * At the end of a milestone, any issues in `To do` or `In Progress` need to be moved over to the next sprint (if still relevant) or turned into new issues. + +### Triage + +Bugs and features will be assigned a sprint, and within a sprint, they will be assigned a priority. The priority dictates the order in which issues should be addressed. An important bug (something that we think is critical for the milestone) is to be addressed before the other bugs. + +### Hardening Sprint + +The final week of the month is what we call the "Hardening Sprint". During this week we will fix the critical bugs and focus the entire week on improving test coverage by building unit and integration tests for any new features. + +Note: +> Currently since we have been refactoring the app, the upcoming hardening sprints will be focused on adding tests to existing features. Our plan is to go app by app and build test + +During this period we make a build available on the insiders channel. We will monitor incoming issues from this release, fix any critical bugs that arise, and then produce a final stable release for the monthly iteration. + +## QA testing +We perform QA testing when features are merged into `develop`. We use automated end-to-end testing to provide a strong foundation for functional testing. + +--- + +# How we manage our code + **Source control:** Git - + +**Source code:** All our repositories are stored on [GitHub](https://github.com/hikaya-io). + **Branches:** - -We have 3 main branches in our repo: -- `Dev` - All bug fixes and enhancements -- Feature branches (i.e. `ACT-001`) - All feature branches must be named like: ACT-001 (where ACT-001 is the issue number on GitHub) -- `Staging` - This is our QA testing environment -- `Master` - Clean code in production environment - -**Hot-fixes & bug-fixes** - -- All pull requests should be based off of the `Dev` branch. -- All branch names should follow the issue number such as: `ACT-001`. This should be the Github issue number. - -**Commits (Smart Commits, only for Jira)** - -- For us to be able to track and link our issues on Github, we use smart commits (This is for issues tracked in Jira). Below is an example of smart commit: - - ACT-001:- Update Activity UI based on styling guide - - ACT-001:- is the issue number on Jira - - “Update Activity UI based on styling guide” Is the commit body. This should be as descriptive as possible. - -**Pull Requests** - + +We use 3 main branches in all our repositories : + +`Dev` (or `Develop`) - All bug fixes, defects, and tasks.
+`Feature branches`: All feature branches must be named like `123-explanation-of-feature-fix`, where 123 is the issue number on GitHub.
+`Master` - Clean code in production environment
+ +> **Note:** +> * All pull requests should be based off of the `develop` branch. +> * All branch names should follow the issue number such as: ACT-001. The numbering should follow the auto-generated GitHub issue number. + +## Commits + +We use Github to track **Issues** and **Pull Requests** for all our work. When making commits, please ensure that you have create a separate branch off of the main `develop` branch before you begin making changes to the source code. Feel free to make commits as often as possible to your branch. If the issue you are working on has been open for a few days, consider pulling in the latest changes to keep in up to date with the main `develop` branch before you create a Pull Request. This will help you avoid merge conflicts when raising your Pull Request. + +### Commit message format +To ensure commit messages are readable when going through project history, we use a common commit message format. The message format by [Angular](https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines) is very comprehensive and we find it useful to follow. + +Each commit message consists of a header, a body and a footer. The header is mandatory with the body and the footer as optional given the size of the commit. The header has a special format that includes a type, a scope, and a subject, where the scope of the header is optional. + +``` +(): + + + +