MoSCoW categories classify code-review comments by priority so authors can distinguish required changes from optional improvements and personal preferences. Each comment begins with M:, S:, C:, or W:. section 6.1.2
Use the categories as follows:
- Must: address the change before approval; it cannot be ignored. section 6.1.2
- Should: propose an obvious improvement; the author needs a reason to ignore it, and the reviewer should agree. section 6.1.2
- Could: suggest an improvement beyond the original task; the author may ignore it without explanation. section 6.1.2
- Would: express personal preference or offer an educational suggestion, especially for a junior developer. section 6.1.2
Formatted review comments
M: This should import 'ts/components', not 'ts/comps'. S: 'item' is a vague name. Change to 'saleItem'? C: A 'top 10 products by region' report would be helpful! W: I wouldn’t have used a loop here. section 6.1.2
Table 6.2 MoSCoW categories and their uses
|
MoSCoW Category
|
Use for
|
|---|---|
Must:
|
• Changes that have to be addressed to be approved. These can’t be ignored.
|
Should:
|
• Suggestions that are an obvious and clear improvement. As an author receiving a
Should comment, you have to give a reason to ignore it, and the reviewer has to agree. Third parties can be brought in when there’s no consensus on what to do.
|
Could:
|
• Improvements or niceties that the reviewer thinks will improve the overall codebase in some way but are likely going above and beyond what the original task requires
• Ignorable by the author; no reason needed by the author to ignore
|
Would:
|
• Those “I wouldn’t have done it this way” comments that are 100% personal preference
• Guiding suggestions for junior developers with the intent to educate
|
Compare the category definitions and the level of obligation attached to each priority. section 6.1.2
