Share via

Check-In Policies Pack Feedback Request

  • Article

I have decided to skip the post about merge and deleted items for today in order to get some feedback from you on Check-in Policies. Currently, we are thinking of releasing a check-in policy pack out of band that includes some very commonly used policies, an example being "Check-in comment field cannot be empty".

 

The reason why I say thinking is that we need enough customer evidence to really justify the investment (we have some but not a lot), if we don’t invest time in this we can divert the effort to other highly requested items, hence the dilemma and trade-offs. So, this is where your feedback comes in: "Would you like us to release a check-in policy pack together with some best practices and ship that out of band?" (Feedback 1)

 

If we decide to do this then the next question becomes which policies are customers writing themselves that we can standardize and put in the pack? (Feedback 2) The empty comment field is a great example of one that a lot of our customers write and is standard.

 

And finally the next logical progression from here is which policies would customers like to see as examples? (Feedback 3) Maybe you want to write a policy but you think is very complicated and are wandering if there is an easier way to perform that task, etc.

 

Summarizing we need your votes for the first one, the more votes we get the better our decision will be. Then if you have thoughts and ideas on #2, and #3 let us know in the comments.

 

Thanks,

mario

Comments

  • Anonymous
    September 13, 2006
    We are in the (very early) planning process for the next TFS Power Toy release.  You can read my...
  • Anonymous
    September 13, 2006
    Microsoft bloggers frequently blog their interest for receiving your feedback on ideas to improve our...
  • Anonymous
    September 13, 2006
    I think a policy to warns folks that a partial checkin (not all pending changes are checked in as part of the changeset) could potentially break the build.  It could suggest shelving the files that won't be checked in, reverting back to the workspace baseline versions for those files and requalifying (compile & test) before continuing with the partial checkin.  Yeah we're seeing a number of broken builds occurringd due to partial checkins.  Of course perhaps CI is a more appropriate response to this problem?
  • Anonymous
    September 13, 2006
    Would you like us to release a check-in policy pack together with some best practices and ship that out of band?  

    Yes, please!
  • Anonymous
    September 13, 2006
    This 'pack' is not something I really need at the moment. I'm able to enforce the comments policy with the checkforcomments policy that's on the web (google it). I use this policy, the ForbiddenPatterns policy and the CustomPath policy.
    If I need anything else, I'll hopefully find it out there or write it myself.
    What I'd really like to see is SP1 for the product and more so Visual Studio 2005 which is appallingly buggy.
  • Anonymous
    September 13, 2006
    Feedback 1: I think the pack would be a great idea.

    Feeback 2: I'm not sure on this. I'm looking to enforce standard C# style rules, but it looks like many of those policies already exist. Maybe a single toggle specifically for naming conventions? Search and destroy on hungarian notation, missing { brace going into for loops, etc.

    Feedback 3: Personally I'd like to see example policies that check the case on identifiers (although it looks like many of these policies already exist).

  • Anonymous
    September 13, 2006
    Feedback 1:  Yes please.

    Feedback 2:  Enforce Comment, Enforce a successful compile since last edit (no errors, optionally no warnings)
  • Anonymous
    September 13, 2006
    Mario Rodriguez, a program manager on TFS version control, is seeking your input on what you need...
  • Anonymous
    September 13, 2006
    Mario Rodriguez, a program manager on TFS version control, is seeking your input on what you need...
  • Anonymous
    September 13, 2006
    Would you like us to release a check-in policy pack together with some best practices and ship that out of band?  

    Yes, please! :)
  • Anonymous
    September 13, 2006
    Mario - I feel obliged to reply to you as you were obviously reading a comment on the forums I made.

    Feedback 1: I think a pack would be a good idea or at least a reference of "good" policies that have been created. I think it would be helpful though if the pack offered an easy installation route for the policies or showed how this could be done simply.

    Feedback 2: Apart from those already mentioned, I think the Time that Task policy that allows developers to enter time worked to date on a task at code check-in time would be useful to include.

    Feedback 3: I think a pack should also describe how to do certain things by way of example; e.g. how to prevent check-in of code if a certain field in an associated work item has a certain value. This is useful for forcing something like a peer review to take place if a field of Review Required is set.

    Extending this further to be able to check if a field in the work item is inappropriately set would be another example; i.e. If a peer review is required then make sure the peer reviewer field has a valid user entered, but NOT the user who is doing the check-in.

    Ultimately a set of examples that show how to manipulate work items and also how to reference the user would be very useful.

    Regards

    Steve
  • Anonymous
    September 14, 2006
    The comment has been removed
  • Anonymous
    September 14, 2006
    Aaron Hallberg on Team Build API: GetBuildURI and GetBuildDetails.

    Brian Harry on The Next TFS Power...
  • Anonymous
    September 14, 2006
    Hi, I have a suggestion on Code Analysis check-in policies.
    We have customized some naming rules. Hence some default naming rules don't apply and we disble them.
    Currently in TFS we have to configure which all rules to run for each project.

    It would be good if we can have a central way of configuring the set of rules for all the projects, rather than setting them at each project.

    Individual project admin should have the ability to override the configured set of rules.
  • Anonymous
    September 22, 2006
    The comment has been removed
  • Anonymous
    September 27, 2006
  1. Yes please to the pack.

    2. I've downloaded and extended TimeThatTask so that the update takes place after the checkin event.
      I've created an EnsureReviewerValidity policy that checks a name in a 'Reviewer' Checkin note, that in turn generates a Review work item after the checkin event.
      I've downloaded EnsureCommentIsPopulated and CustomPath.

    3. I'd like to see a policy that checks your workspace is up to date before allowing you to checkin.

    Thanks.
  • Anonymous
    October 08, 2006
  1. Please, Please add a checkin policies pack
  • Coding convention policies would be a huge plus.
  • Required comments is a must.
  1. I noticed that someone had mentioned that entering the time required for checked in items, would it be possible for that data to be added to the TFS Warehouse along with any other info which could be calculated during checkin. An example that I am thinking of would be the LOC associated with the Check-In.

  • Anonymous
    November 20, 2006
    There was a recent TFS Version Control Blog post which asked the community for feedback regarding TFS

  • Anonymous
    June 18, 2009
    PingBack from http://thestoragebench.info/story.php?id=8512

  • Anonymous
    August 10, 2009
    Not only would policy packs be useful, so would sample or templates for creating written policies or guidelines just as there are naming convention and style guidelines for .net.