Lessons learned from bountying bugs
From the post:
A bit over a week ago, I wrote here about the $1265 of Tarsnap bugs fixed as a result of the Tarsnap bug bounty which I’ve been running since April. I was impressed by the amount of traffic that post received — over 82000 hits so far — as well as the number of people who said they were considering following my example. For them and anyone else interested in “crowdsourcing” bug hunting, here’s some of the lessons I learned over the past few months.
I suppose next to writing documentation, debugging is the least attractive job of all.
Curious if anyone has used a bountying bugs approach with their topic maps?
Seems like it would be a useful technique, particularly with large topic maps spread over organizations for users to get some sort of reward for reporting errors.
I suppose it isn’t a really big step to giving at least some users the ability to suggest new topics or merges.
I think it is important to remember that our users are people first and users of topic maps and/or software second. We all like to get rewards, even small ones.
It occurs to me that if a topic map is only one resource of many, that a user could consult and the plan is to move users towards relying on the topic map, offering incentives for use of the topic map would be an extension of the reward idea.