-
Notifications
You must be signed in to change notification settings - Fork 86
Howto: Create Review Proofs
Not every Review Proof has to be backed by an actual code review. E.g., 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 a package has severe 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 hasn't been 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, a Review Proof with understanding: none is more useful than no review at all. You don't have to 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, a 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 one, summary judgment. More nuanced information should be put into the 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.