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
  • Contributing via GitHub
  • Major contributions
  • Style considerations
  1. Documentation

Documentation

PreviousOpen Source DesignNextContributing docs via GitHub

Contributing via GitHub

Anyone may suggest changes or additions to the documentation that you are reading. All that is required is a Github account and some familiarity with the format.

Assuming you have a github account and there's some document you would like to edit, please follow this .

Major contributions

If you have to remember three words from all this, those would be: concise, direct and neutral

If you are planning to provide a major contribution, consisting of significant amounts of content, we may be able to help you.

For instance, if your intention is to edit a lot of pages or to create new complete sections, you may find it easier to do that using the GitBook web interface.

In order to obtain permission to edit via GitBook, you will need two things:

  1. A github account

  2. Send us a message on

Style considerations

Our intention is to make our documentation available to as many people as possible. The Ushahidi Platform is used all over the world by people of different cultures, ages and linguistic backgrounds.

We use the English language as it is the most widely spread language for global communication. While making this choice, we must be mindful of the diversity of our audience. Not all our readers may be comfortable with English. We must not add to their burden with confused explanations, complicated structure or obscure wording.

Here are a few things to keep in mind.

  • Keep your pages short. If you have to scroll down more than two or three times so as to review the content of your newly created page, it may be worth splitting that content up into two or several different pages.

  • Keep your text to the point. Avoid at all costs quickly rambling through different ideas or adding to the same page concepts that are not directly connected.

  • Explicit is better than implicit. Be mindful of what you are assuming your audience to know. If you would rather not go into the length of explaining something, consider linking to an explanation. If you feel some level of knowledge is required to go through your text, be clear about it. Also consider adding links that may help your audience obtain that knowledge.

  • Use paragraphs effectively. Try to keep your paragraphs short. Avoid mixing ideas in the same paragraph. A new idea, perspective or concept is a great opportunity to start a new paragraph. Complex ideas can take several paragraphs. If your paragraph contains more than 8 lines or sentences, this is a strong signal for you to consider splitting that paragraph up.

  • Don't use sophisticated language. Our documentation is not intended only for native or advanced English speakers. Any person with a beginner to intermediate level should be able to read this without giving up.

  • Use short sentences and neutral, standard vocabulary. Please try to write in short sentences. Avoid long sentences with multiple conjunctions. Also use vocabulary as plain as possible. Avoid obscure words and local, excessively colloquial or elaborate expressions. If you feel it's absolutely necessary to use a specific, not widely used term, please consider linking to its definition.

Markdown
guide
techdocs@ushahidi.com