Skip to content

Latest commit

 

History

History
139 lines (89 loc) · 5.45 KB

CHECKLIST.rst

File metadata and controls

139 lines (89 loc) · 5.45 KB
Raw

IATI Dashboard Checklist

https://github.com/IATI/IATI-Developer-Documentation/blob/master/code-checklist.rst

We should know which code is 'ours'

This is ours

All code should have a lead person identified

Dale Potter - https://github.com/dalepotter

Our projects/code should be appropriately branded.

In absence of branding guidance this uses a plain twitter bootstrap theme.

Our code/projects should be in version control and present links to issue trackers  and source code.

https://github.com/IATI/IATI-Dashboard/

Each piece of code should have a document(!), a roadmap, and estimate of resources, and a licence

Released under the GPL license

We should be confident that updates to our code will not break existing functionality

It’s a static site generator, so if we check the output is okay, it’s fine.

It would be good to have an automated process of doing this, but there currently isn’t.

It should make sense in the way people access our tools/code

At http://dashboard.iatistandard.org

Our code should be on our servers - we should be able to monitor the performance of those servers

All the code for this is now on IATI servers.

We don't have any particular performance monitoring set up.

We should know how our code is being used - logs!

We have google analytics, and the server has web logs for page accesses, and logs of the complete process.

Our code will need to adapt with schema changes and changes to external systems upon which it relies

This relies on the stats generated by a different piece of software (IATI-Stats), which itself relies on the Standard and the CKAN API. If those statistics are generated differently (or output differently) then this code would be affected.

It also relies on the Github API (v3), and Github gist.

The code relies on python modules, which may change over time. This may have implications for the server requirements to host the application.

Developers should be able to find useful resources and help easily

  • Link to the source code and issue tracker are in the footer.
  • Javascript support tab is in place that links to Zendesk.

Each project should clearly describe how other developers can get involved

Has a CONTRIBUTING.rst file

We should be able to communicate with the users of our code.

There is room on the homepage for notices.

There is a forum on support.iatistandard.org for consultation about the Dashboard Publishing Statistics tabs - http://support.iatistandard.org/forums/21204695-Dashboard-Publishing-Statistics

Nothing more general is in place.

Users should be able to communicate with us about our code

The Support tab is in place.

If people visit the source code pages they can contact the team there.

We should protect our users privacy

  • This is just a website, same concerns as our other websites.
  • No logins, or collection of users data
  • The Dashboard sets cookies. Cookie code should be considered.
  • Terms and conditions have not been written and may need to be.

We should be clear about how we work with contractors

N/A

If our code works with IATI data, have we considered how it will work as the IATI datasets grow, both in terms of individual file size and as a corpus

This could become a problem for the Dashboard, as it relies on running code across the entire dataset. Currently the complete process (including download and stats code) for generating the dashboard takes several hours.

Our code should be secure

The dashboard doesn’t pose any new security concerns because it’s all a static site.

We should know that our deployed code is working properly

As this is a static site it is either there or it is not.

If any of scripts return a non-zero exit status the site will not be updated. So at worst an out of date site will be displayed, but not a broken site.

We use travis to check whether is has updated by noon in a given day - https://github.com/IATI/IATI-Website-Tests

There is a concern for knowing that the dashboard is accurately displaying what we think it should. As it relies on number of other services it could be displaying inaccurate data.