Russ, I've reviewed your new patch. I haven't been participating in this discussion before, but I think it is fair to say that I have significant experience with these sorts of normative language discussions and Debian policy in general. I agree with all your changes (with one question below). My review was insufficient to catch changes you should hav made but did not. One question: +The Release Team may, at their discretion, downgrade a Policy requirement +to a Policy recommendation for a given release of the Debian distribution. +This may be done for only a specific package or for the archive as a +whole. This provision is intended to provide flexibility to balance the +quality standards of the distribution against the release schedule and the +importance of making a stable release. I wonder if that should be can (or is permitted) rather than may. Saying it is optional implies that the policy is not making a recommendation on whether they should make such changes. I guess that's true, but either: 1) it's in scope for the policy to permit this. In which case may is too weak. 2) It's out of scope, in which you should not use normative language at all. Some will argue that it's inherently out of scope for you to make that recommendation because of separation of concerns between the policy editors and release team. I think it would be inappropriate for the policy editors to update what policy says about what the release team can do without sign-off from the release team (or change in the delegation text). For example it would clearly be inappropriate for the policy editors to change "is permitted" to "must not" in the above without the release team agreeing. But I think whether policy makes normative documentation in this space should be decided based on what is best for the project rather than on who all would have to approve such changes. That said, can is simpler. Regardless of may, can, or is permitted, I second your patch.
Attachment:
signature.asc
Description: PGP signature