Dermot McCluskey wrote: > As a convenience, eg the Approver spots a small, obvious > mistake and decides to fix it themselves, rather than > go back-and-forth with the submitter. > > I know Christian (and others?) do this frequently, so I'll > let them speak up for how useful this functionality is. I > think it's also been useful for them to touch a file in order > to kick off a build.
I'm really uncomfortable with that functionality. It puts the approver in the place of changing someone else's work (possibly) without that person's knowledge or agreement. As convenient as it might be, I'm not really comfortable with this. The little things that people need to fix are part of the education process and getting used to performing project work. Also, reviewers need to get use to delegating that work to the submitter so that they can *learn* about the correct process for submitting packages. Allowing the reviewer to edit the and approve materials violates the fundamental idea of a peer review process. There's just too much room for accidents in my view with letting the approvers be reviewer, editor, and approver no matter how good their intentions are. There are a few possible solutions to me: * The submitter gets to control over whether others are allowed to edit the submission. * Email notifications are sent and a comment is logged against the submission with the exact differences any time a submission is changed so that its clear who has changed what and hopefully why. Cheers, -- Shawn Walker
