Platform Contributor Guide
[Legacy v3] Platform
[Legacy v3] Platform
  • 👋[Legacy v3] Welcome | README
  • Contributing | Getting Involved
    • Specific tasks needed for COVID19-support
    • Add code to Ushahidi
    • Encouraging contribution from non-developers
  • Frequently Asked Questions
  • Join the Ushahidi community
  • Contributors ✨
  • 🛣️ The Ushahidi Platform Roadmap
    • V2-V3+ Migration tool
  • Privacy and security best practices
    • Security as a user
    • Security for deployment admins
    • Security for deployment hosts
  • Development & Code
    • Development: Overview
    • How to get the source code
    • Setup Guides
      • Installing for production environments
      • Development environment with XAMPP
      • Development environment setup with Vagrant
      • [Client] Setting up the Platform Client for development
        • Migration from AngularJS
      • Setting up the Pattern Library for development
      • [API & Client] Bundled release install
    • Add code to Ushahidi
    • Development process
    • Coding Standards
    • Track and submit issues in Github
    • Upgrading Ushahidi
      • Upgrading to latest release
      • Upgrading from V3.x.x to V4.x.x
    • ⚙️ Installation Helper‌
  • Tech Stack
    • API Documentation
    • Third party app development
      • Web hooks
    • Database | Tables overview
    • Database | Database Schema Diagram
    • Database | Table details
    • 📐Architecture
    • Use case internals
  • QA & Testing
    • The QA process
    • How to run QA tests
    • Defect Management
    • How to write QA test scripts
    • Hotfixes
  • Front-end development
    • Changing UI styles: introduction to the pattern library
      • File-structure
      • Installing new packages
      • How to Apply to the Platform
      • Using the changed styles in platform-client
      • Syntax and Formatting
      • Grid, Breakpoints, & Media Queries
      • Variables
      • Mixins
      • Helpers
      • Icons
      • Create a New Component from Scratch
      • Read Direction
  • Design
    • 🎨Design: overview
    • 'Best practice' design
    • Ushahidi Platform 'Sticker Sheet'
    • User testing process
    • User testing script examples
    • Synthesising user testing results examples
      • Synthesis example 1
      • Synthesis example 2
      • Synthesis example 3
      • Synthesis recommendations example 1
      • Synthesis recommendations example 2
    • Open Source Design
  • Documentation
    • Documentation
    • Contributing docs via GitHub
  • Translation
    • Localization and Translation
  • The Ushahidi Platform Facebook bot
    • The Facebook bot
      • Installing the bot
      • The bot script
  • Hackathon and events
    • Installathon, May 2019
      • Welcome to the hackathon!
    • Write/Speak/Code 2019
    • Open Design: Bangalore
    • Open Design: Taipei
    • 📑Google season of docs
    • 💻Google Summer of Code
      • GSoC 2024
  • Enhancement Proposals
    • Exchange Format
    • Importing data from previous versions
Powered by GitBook
On this page
  • Plan & Reflect Phase
  • Reflect:
  • Plan
  • Development Phase
  • Open source contributors
  1. Development & Code

Development process

The work for the platform is done in 3 week cycles and is composed of 2 phases.

A Cycle is 3 weeks long, and it’s composed of 2 Phases:

  • Plan and Reflect phase: 1 week long

  • Development phase: 2 weeks long

Plan & Reflect Phase

Reflect:

The dev team reflects on process and iterates on it. This is done through retrospectives, tracking and notes from the cycle.

Plan

The dev team prepares all work for the upcoming Dev Phase. This includes:

  • Writing a Spec for each Issue in an Epic.

    • Writing demo scripts

    • Writing test scripts

    • Writing what needs to be done (Intended behavior)

    • If necessary, tech spec is written.

  • Breaking tickets down to a small, releasable unit of work

  • Dropping tickets that don’t serve the goal of a cycle, or would put the cycle at risk.

    • Dropping is reviewed with PM to be aligned and based on priorities.

    • Example: In Cycle #0, we just want to be able to export data correctly. Anything that does not serve that goal is of less priority.

  • Making sure we have the designs we need to start dev

  • Mapping out how the dev phase has to run. For instance, flagging dependencies and having an idea of what goes first/last

Development Phase

The dev team does the work they planned with the PM, and as they move forward, adjust as necessary.

In short: The development phase is when we go from zero to demo in each ticket.

Tracking:

Cumulative Burndown Charts are generated every 2 days so we can easily see the trends in our cycle.

DONE Reviews:

For each ticket, the devs share a video with the PM demonstrating the work, or get on a demo call. This work either gets accepted (goes into final testing phase), or rejected (goes back to Development).

Open source contributors

PreviousAdd code to UshahidiNextCoding Standards

Open source contributors does not need to join and follow the cycles, you can do it in your own pace. We have marked issues that are up for grabs by community devs "​" in github.

Other tasks that we haven’t labeled yet may be suitable for work. Feel free to the team if you intend to work on something that grabs your attention.

Community task
contact