It seems the Data Quality Tracker system is not active, so I am creating this topic to report quality/accuracy issues with the data.
Date updated: 2016-04-18 14:37
Issue: activity-date iso-date=“1013-07-30” type=“end-actual”
Publisher: Publisher: Mercy Corps Europe
Dataset: MERCY CORPS EUROPE Activity File-et
Date update: 2016-04-30 11:14
Issue: activity-date type=“1” iso-date=“1016-03-14”
Publisher: Denmark - Danida - Danish Ministry of Foreigh Affairs
Dataset: Denmark, complete activity file 5
Date update: 2016-06-08 05:25
Issue: activity-date type=“end-actual” iso-date="2414-04-01
BTW this page on the Dashboard - http://dashboard.iatistandard.org/dates.html - once sorted by the appropriate column also provides a useful list of dates in IATI data that look to be too early/late.
Thanks for flagging @Moqri and as you point out we are not actively using the Data Quality Tracker at the moment. The intention is to further develop the IATI Dashboard so that any data publisher or data user can easily see if there are data quality or other issues in any published IATI file that need fixing etc. As a result we have also posted a separate call to all members and beyond of the IATI community for their input and ideas as to how we might enhance the IATI dashboard to better service their needs (please see IATI Dashboard & Data quality - your views welcome). Please do add any thoughts or ideas that you might have.
Also in slightly slower time, as the IATI dashboard develops, we shall probably look to decommission the Data Quality Tracker. However, if anyone has any thoughts or issues in relation to this product please do let us know?
Just reopening this topic – it would be good to have somewhere to flag issues with publishers’ data that are not automatically detectable by something like the Dashboard. The Data Quality Tracker used to serve such a purpose even if the user interface wasn’t so nice.
For example, in the EU’s data, at hierarchy=2,
Accountable organisation is being used to publish the implementing organisation, whereas it looks like
Implementing organisation should probably be used in this case. That’s not something that you would expect to be automatically detectable by the IATI Dashboard.
Any thoughts on where this could best be located? Perhaps Github Issues, though it would be good to have some more user friendly way of showing that information. I think the goal should be that users can log and view known issues with publishers’ data and that publishers can get informed about potential problems that users have flagged. Just emailing the relevant publisher is obviously an option, though that doesn’t help other users gain awareness of known problems, and is difficult to track whether issues have been resolved.
Assuming that the majority of issues that people want to raise are publisher specific (plenty are not but these are probably best dealt with through another process), could for each publisher get a page on the Data Quality Tracker in the same way as each publisher has a stats page?
Matt’s suggestion sounds like a great idea to me. As a publisher, we could check issues reported by users, and perhaps indicate how/when they are resolved? Perhaps an automatic notification could go to publisher’s contact point whenever something is added to the page.
Thanks for all the good points raised here and there is definitely a need for some sort of mechanism that allows data users etc. to flag issues not automatically detected by the dashboard or IATI validator etc. It is already our intention to enhance the dashboard at some point to automatically notify a publisher when errors with published data have been detected. However, we should also look at establishing a public reporting method (via the dashboard?) to meet the additional requirement.
That sounds great Wendy. Do you have any idea about a timeframe for this? If it was going to take a while, maybe we could already start with a shared google doc as we are sitting on a lot of already identified issues?
It would be also great if the page had an ability to group issues, for ease of viewing, and to be able to join together multiple reports of the same problem.
Thanks @matmaxgeds although I have to be honest that we would be unlikely to schedule any improvements for this to the dashboard in the near future. As a result I am therefore wondering if we should look (at least for the short to medium term) to resurrect the use of data.tickets? The dashboard and data.tickets are still linked (if a publisher has had an issue raised on data.tickets then it still gets flagged up in the data quality section of the publisher’s individual dashboard page). However, would be useful to know what you and other publishers think about this?
Thanks Wendy, from my perspective this looks like it might be a good fit and great not to reinvent the wheel! It would be good to understand why it was hibernated though before we resurrect it. 187 closed tickets suggests that it was having some impact so perhaps some other reason that there haven’t been any tickets since 2014?
It would be great if resurrecting it could find a way to include Yohanna’s point about providers being able to share how they solved issues - this would be very helpful to find out new ways to fix things.
I also just tried to join data.tickets but couldn’t see how to get a username and password - am I being thick? Ideally this would be the same as my current IATI site login?
Hi @matmaxgeds - the use of data.tickets was mostly before my time with IATI but @Wendy may be able to comment more on its hibernation. Assuming of course, it was an intended hibernation, rather than people stopped using it…!
From a technical point of view, it does seem that there is an issue with signing up for an account. We’ve added it to the list of projects for later this week, and will report back then.
Thanks for update @dalepotter. Also, @matmaxgeds the reason we originally stopped using data.tickets was because we weren’t at the time (pre IATI dashboard so things have moved on now) getting much traction with users to use it. Some users were also confused as to when they should use data.tickets rather than contacting the IATI Help Desk? In addition, we were (and still are) aware of the number of different products that users were having to sign up to and create accounts for in order to use the different IATI services and therefore didn’t want to add any additional products at that time either.
For the issue of multiple sign-ups, perhaps this can share the login with another product?
For the issue of confusion, perhaps so text indicating that this is specifically for reporting problems with another publisher’s data? But I can also see how this could end up having a lot of crossover with e.g. suggestions to edits to the standard.
Taken together, maybe we just need a new theme on the iati discuss forum for this? The multiple accounts issue would be solved, and it would be easier to cross-reference other discussions?
I am more worried about establishing that there is a) demand, beyond me, @YohannaLoucheur, @markbrough, @Moqri and b) that there is some evidence that the issues identified might get fixed…the list of outstanding issues suggests maybe not. Perhaps something to discuss at the TAG?
Thanks @matmaxgeds and as above the main reason for reinvigorating data.tickets rather than posting to a forum on Discuss is because it is still integrated with the IATI Dashboard so a publisher when looking at their publisher page would (hopefully) notice that an issue had been raised.
However, we would be interested to hear the views of others as you suggest.