Skip to content

Latest commit

 

History

History
67 lines (41 loc) · 3.95 KB

README.md

File metadata and controls

67 lines (41 loc) · 3.95 KB
Raw

General-information

Project wide information on how to contribute and collaborate.

  1. Using Github's Issue Tracker
  2. Contributing Code as a Developer

Using Github's Issue Tracker

Submitting Feature Request or Reporting Bugs

Here are some guidelines to using the Github issues for communicating and managing tasks.

Quick Reads

If you are new to Github issues. Please take some time and read this fast and gentle guide to Mastering github issues:

Labels

We use Labels to categorize issues created. For the project, we have 2 dimensions to which an issue should be tagged on. Type of Issues: Feature or Bug

Severity: High or Low

Type of Issues

Barring special cases, when submitting an issue make sure it is tagged with one of the following labels:

Feature: This if for issues that adds new functionality to the application. Use feature also for issues that enhances or modify existing behaviour.

Bug: Use the bug tag when reporting anomaly in the system.

Severity of Issues

When submitting an issue, also ensure to add the severity label. You have one of the following labels to do just that:

High: There is fire on the mountain! The wife is going into labour! You get the jist? It should be done as soon as possible!

Low: Really good to have...but It can wait.

Submitting Feature request

When creating a feature request, try to be detailed as possible. Understand that for the feature being requested to be built in the exact manner you want, the details need to be specified. Being explicit, even over the tiniest details is prefered. Avoid assumptions.

Reporting Bugs

When creating bug reports, please ensure to include the reproduction steps. “it does not work” is not good enough. We would need more than that for us to be able to identify the problem and fix it.

Couple of important things to always include in bug reports:

  1. The exact steps that led to the issue. What you clicked, what you were expecting, what you got instead.

  2. If you can consistently reproduce the issue. That is if the issue happens all the time, or if it happens sometimes in a random, unpredictable way. Issues that happens all the time are easier to solve.

  3. Screenshot of the error page when possible.

Where to create issues

Remember the Yorubaname project consist of two separate application with two separate git repository. The Yorubname website: and the Yorubaname Dashboard:.

If the issue is about the dashboard, put it on the dashboard issue tracker: If it is about the website, put it in the website issue tracker:. When in doubt put it in the website’s issue tracker.

Contributing Code as a Developer.

The yorubaname code base consists of two repositories. Yorubname website: and the Yorubaname Dashboard:

A way to quickly start contributing code is to check the submitted bugs in the issue trackers (for Yorubaname website and for Yorubaname project), make a fix for it and create a pull request.

You can read about how to create pull requests here:

Each of the repositories have README’s that give a brief overview of the architecture of the project. The README’s also contain instructions on how to checkout the project and run locally. So do conult them.

In case you have any questions, we have a dev channel on Slack. Feel free to swing by and talk to us. The channel is https://yorubaname.slack.com/messages/dev/