-
Notifications
You must be signed in to change notification settings - Fork 97
Howto: Create Review Proofs
Not every Review Proof has to be backed by an actual code review. Eg. if a CVE was discovered affecting one of your dependencies, you don't have to actually review it to mark it as rating: dangerous. If package has a sever functional problems (like performance), you don't have to review it to warn other users about it. Or if you're sure that the package weren't tampered with and is from a trustworthy source, you might want to mark it as such . As long as you indicate that you actually haven't reviewed it, it allows other people to filter-out such Review Proofs if so they desire.
Similarly, Review Proof with understanding: none is more useful than no review at all. You don't have understand the code, to see that at least it isn't obviously malicious. It's better to truthfully and conservatively indicate your understanding, than mislead other people.
While it's still open for debate, the current opinion is that additional fields are not useful for the downstream users. Instead they just complicate their life, putting the burden of the decision from the reviewer onto them. At the end, downstream user of a review just wants to know: "is it OK to use this package or not?". Your role as a reviewer is to provide that judgment.
Every additional field is just a complication, additional work and a barrier to do a review in the first place. When reviewing a crate one has to commit to a one, summary judgment. More nuanced information should be put into comment section.
If the package under review is secure, but has poor functionality it should just get rating: negative or rating: neutral. If it is insecure, it should get rating: dangerous.
Another technical reason why it's better to have one field right now, is that it's easier to add new fields in the future, than deprecate existing ones. Therefore it's just simpler and more conservative to start with just one.