User Tools

Site Tools




Basic concepts and guidelines

User Guides

For users

For mappers


Learn about Dokuwiki


This is an old revision of the document!

Reporting bugs and/or feature requests on github

Who is this guide for

  • External users testing the platform
  • Internal staff helping improve the code base

What this guide teaches

  • How to report bugs or problems currently being reproduced on the platform
  • How to request implementation of new features and enhancements

Things to know in forehand

Issues should be filed on the github repository relating to the corresponding workstream

Depending on what part of the system the bug report of feature request relates to, Issues should be raised in the corresponding github repostory.

In order to keep it simple. Issues should be raised in one of the following repositories. Each of them corresponding to one of the workstreams ODI's work is usually organized into:

Tech workstream Everything related to the platform's code-base. Bugs, general issues or feature requests for both WP front-end, CKAN back-end or any other component can be filed here.

Data workstream Everything related to data work. Missing, incomplete or incorrect datasets. Requests of adding new datasets to the CKAN instance, etc..

Editorial workstream Everything related to the news articles, profiles, stories, etc… maintained on the WP instance. Missing or incorrect information, requests for adding a specific news article etc can be filled here

Localization workstream Everything related to the localization of the platform's components and contents into local languages. Issues related to the way strings are translated on transifex or issues encountered on the public-facing texts can be filled here.

Some useful resources to read/watch before

Make sure that the Issue/Feature that you are raising has not been reported yet

In order to avoid creating duplicated Issues, the reporter should first check if it has not been reported yet. For that, it is very helpful to use the search function of the Github Issues.

Example search for “data page”…

Reproducing and describing bugs

Keeping a consistent methodology for reproducing bugs is very important. Once a tester identifies an error, the conditions for repeating it need to be gathered in order for developers to reproduce the scenario and be able to test solutions. This process consist on following steps:

  1. Provide a descriptive title
  2. Provide a URL (link) of the site where the error is appearing
  3. Provide a list of actions that need to be done to make the error appear. Example: Scroll down to bottom of site and click on the download link.
  4. Provide one or more screenshots showing the problem.
  5. Specify the environment in which the issue appears (operative system, browser version). Example: The problem appears on windows using firefox version 48.0 but does not appear on OSX using safari.
  6. Specify what is the expected behaviour and how the current status does not reflect it.

Requesting the implementation of a new feature or enhancement

Instead of informing of an error on the functionality, a feature request proposes the implementation of a new functionality or the improvement of an existing one.

While creating a github Issue with a feature requests please:

- Add design mockups on how you would like the feature to look like - Provide detailed description on how the new feature should work and how the user is supposed to use it. - Specify links on the pages/modules where the new feature should be implemented.

Creating an issue on github containing the bug's or feature request details

Once the information specified above has been gathered, open the corresponding github repository. Example: and click on Issues » New Issue, set a descriptive title and add the steps for reproducing the error, the screenshot and further information in the description.

public/bug_reporting.1508223644.txt.gz · Last modified: 2020/06/23 15:03 (external edit)