Hi @Jonathan, and welcome to the community! Thanks for going to the effort of setting up an account here to pass on your feedback, it’s appreciated 
If you’re interested in sticking around, feel free to introduce yourself!
I’ve had a read of the feedback you gave on the deleted post (although the content of original post seems to have gone).
First of all, it’s great to hear you like the idea behind the task. But I’m really sorry that it was a deflating experience for you.
You’re absolutely right that the quality of much of the data is not great and I totally take on board your feedback about this being frustrating. It’s probably fair to say that we can sometimes get wrapped up in our own world and not work hard enough to provide the proper context for where this data comes from. So I think it might be helpful to provide this now (bear with me!).
The information about each device was written down (usually on a piece of paper or a flipchart) by a volunteer at a community repair event, such as a Restart Party or a Repair Café (we filmed a short primer about these a while back if you’re interested). These events serve a number of purposes: as social events to build community, opportunities to learn or share repair skills and so on. They’re good fun. But data collection is often a secondary priority, which means that when things are busy, the detail of each repair might not get recorded. That’s why you’re seeing descriptions like “battery fault”. It’s also worth knowing that the data comes from hundreds of different community groups from around the world, which is another reason the quality can differ so much from record to record. (For example, many of the groups in Germany do provide excellent data - try refreshing BattCat in German a few times to see what I mean. - click here to return to English)
As a loose network of communities, we’re always trying find ways to improve the quality of data we record at repair events, but it’s very much an ongoing process and can be tricky given how decentralised we all are.
In the meantime, poor data is obviously not ideal, and while we did our best to remove as much of it as we could from BattCat, I can fully appreciate that having to hit that ‘poor data’ button so often is frustrating.
Ultimately, the aim is to classify as much of the useful data as we can in order to tease out any trends or patterns. We’ve already identified that most of these devices had a battery issue, but we’re keen to better understand what these issues were and what the fix would be. For example, in a similar quest we ran previously, we looked at the main reasons smartphones break and were able to produce some useful data, which has come in handy when engaging with policy discussions.
That said, I’m sure there’s more we could do next time to filter out the poor data in advance to make it a more satisfying task 
Do you think that would go some way to improving your experience? Or does that not quite address what you meant?
In your feedback, you also wondered whether we were building a database of fixes. The answer is yes, we’re doing that too! You can view our full dataset in the Fixometer section of this site. We’ve also combined our dataset with similar datasets from our partners in the Open Repair Alliance (ORA), a network of organisations, who—like us—support community groups to run local repair events. You’re welcome to download the full ORA dataset (you can also download the datasets from each individual partner, including us). The idea behind BattCat is to analyse part of this database to help us draw meaningful conclusions.
I’ll stop typing now, but I hope that’s useful. We’ll certainly take your feedback on board and aim to filter out more of the poor data next time
P.s. I’m not sure who posted it on r/fixit - was that you @Guy? Didn’t know you were a redditor 
(That’s actually a new subreddit for me - it looks brilliant - thanks for flagging it Jonathan!)