I suggest you ...

Disallow TFS checkin policy override

The ability to override checkin policies is in some cases absolutely unwanted. If I use policies I have fairly reasons to do them and dont't want it can be overridden...
'No override allowed' will be much more useful than generate a list of overridden policies and will help enforce code quality.

50 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    elafelaf shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    3 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • Paul CostePaul Coste commented  ·   ·  Flag as inappropriate

        @Teyde it should be up to the customer to make that determination. While I agree in some cases, it really depends on the policy. If I write a custom policy and apply it to a custom path and say that in all cases, check-ins must comply with that policy, and the policy requires that certain static analysis is performed, or some field is filled out, etc. for regulatory compliance purposes, then it is an overstep for Microsoft to say that this is not a valid business case. Let the customer make that call based on their needs.

      • Steve St JeanSteve St Jean commented  ·   ·  Flag as inappropriate

        All check-in policy overrides are audited and there is also an alert email that you can subscribe to. I would suggest subscribing to the alert email and then dealing with the overriding devs as a training/HR issue rather than using technology to enforce compliance.

        There are always emergencies and precluding an override could get very expensive in those cases.

      • teydeteyde commented  ·   ·  Flag as inappropriate

        Maybe it will enforce code quality, but I really don't believe it. The check-in process has little to do with the code itself. ****** code is still ******, even after all the policies are met. I would counter-argue, and say that when I need to override, I have a very good reason indeed to do so. It's usually when the process is counter productive.

      Feedback and Knowledge Base