When providing feedback as a proven tester, please try to follow this procedure as closely as possible. Our aim is to ensure that updates to critical path packages do not cause major functional regressions. Two documents to keep in mind as you test are the critical path definition and the [criteria]. If a proposed update to a critical path package causes problems with the critical path actions, or a new issue or regression which would constitute an infringement of the release criteria, then you provide negative feedback on the update. So, specifically, make sure to check whether each update you are testing causes problems with:
- Booting the system and logging in to a graphical desktop
- Decrypting encrypted file systems
- Network access
- Retrieving and installing updates
Also use your judgement to provide negative feedback if the update has a significant problem by which you think many users would be affected, but bear in mind that ensuring perfection is not the aim of the proven testers project. If an issue is trivial or cosmetic, it may be better to provide positive feedback but note the minor problem in your comment.
Always check the existing feedback on the update before providing your feedback, especially from other proven testers. Bear in mind that there are cases where a problem is genuine but not experienced in all configurations. If you think the update works well in your case but you notice that another tester has reported a major problem, first try and reproduce their problem, and if you can (and you agree that it is significant), give negative feedback. If you cannot reproduce the problem but you believe it is likely to be a genuine issue you simply cannot replicate in your own configuration, it is usually best at present to provide neutral feedback noting that you did not encounter the issue than to provide positive feedback, due to limitations of the current feedback system. In future, the feedback system will be redesigned to handle this situation better.