Why? Just let the project owner hit a button that says "This issue has been addressed" or "This issue is being worked on", adding an optional note, which marks the review accordingly somehow. Then you can look and see how proactive the project owner is in addressing his feedback.
1,392 people rated my project as having 1 star for documentation. I've made documentation better. A few people have now rated it four stars while some still believe it's one star and don't see the point of changing their votes from one star to one star.
I think it's a great idea to show users what parts of a project are weak (it'd help them understand how they can help), but I have the same problem with reviews on Apple's app stores, Android Market, Amazon, etc...
Some of those are handled a bit by the complaints being about previous versions, but stuff on github isn't necessarily versioned.
I guess I am skeptical that a "star" rating could ever be meaningful for Github projects. Frankly, the whole thing seems like a bust regardless if you have a thousand reviews; what kind of meaningful information could you get from a thousand reviews all talking about different versions, different use cases, different kinds of "quality"?
However, for the majority of long tail projects that might have a couple pages worth of reviews, it would be useful feedback, and the project owner could address each review individually with ease.
It may make sense to provide much more weight to the latest N reviews, and a lot less to older, but still to add them into the mix. So your past will weight as well but you can correct your problems and get a better average review.
I like this idea. Software changes over time, so I always have to double-check the date when reading other people's reviews. Especially if the software is developed at a very fast rate, such as Redis.
Another option would be to provide a history of average star ratings, similar to the 52-week activity graph. Then people would be able to see, for example, that most reviews have turned positive since the v2.5 release, etc. Tie reviews to versions and/or commits, and allow people to post another review after X weeks, so that the same person can post different reviews of different versions of the same program.
There could also be something like a time-to-live for a review; say after half a year the mark disappears and you can/should rate the project anew at based on current state.
Comments
The big problem here is that once you address the issues you have to get a bunch of people to change their old reviews.
Why? Just let the project owner hit a button that says "This issue has been addressed" or "This issue is being worked on", adding an optional note, which marks the review accordingly somehow. Then you can look and see how proactive the project owner is in addressing his feedback.
1,392 people rated my project as having 1 star for documentation. I've made documentation better. A few people have now rated it four stars while some still believe it's one star and don't see the point of changing their votes from one star to one star.
I think it's a great idea to show users what parts of a project are weak (it'd help them understand how they can help), but I have the same problem with reviews on Apple's app stores, Android Market, Amazon, etc...
Some of those are handled a bit by the complaints being about previous versions, but stuff on github isn't necessarily versioned.
I guess I am skeptical that a "star" rating could ever be meaningful for Github projects. Frankly, the whole thing seems like a bust regardless if you have a thousand reviews; what kind of meaningful information could you get from a thousand reviews all talking about different versions, different use cases, different kinds of "quality"?
However, for the majority of long tail projects that might have a couple pages worth of reviews, it would be useful feedback, and the project owner could address each review individually with ease.
It may make sense to provide much more weight to the latest N reviews, and a lot less to older, but still to add them into the mix. So your past will weight as well but you can correct your problems and get a better average review.
I like this idea. Software changes over time, so I always have to double-check the date when reading other people's reviews. Especially if the software is developed at a very fast rate, such as Redis.
Another option would be to provide a history of average star ratings, similar to the 52-week activity graph. Then people would be able to see, for example, that most reviews have turned positive since the v2.5 release, etc. Tie reviews to versions and/or commits, and allow people to post another review after X weeks, so that the same person can post different reviews of different versions of the same program.
There could also be something like a time-to-live for a review; say after half a year the mark disappears and you can/should rate the project anew at based on current state.