For all ScintillaNET developers, please follow the following guidelines to make other team member's lives easier and my life much easier as someone who has to coordinate change management.
  • Check-outs: When checking out files do not place locks on files. It is always preferable to merge changes than to undo someones checkout and risk a loss of work. If you ever get a conflict you can't easily resolve, email me the file(s) you want checked in ( and I will merge the files for you. When prompted Always choose the shared checkout option. Also watch out as VS/TFS places locks on certain file types by default (we found this out with SciLexer.dll the hard way :)
  • Check-ins: Ideally all code changes to the main code line should be associated to a WorkI tem. If you don't have a WorkItem for the change you are commiting, go forth and create one. To associate a code change to a work item do 2 things: First tag the check in comments with the Work Item # using the following convention {wiXXXX}. As an example: {wi1234} The MadeUpMethodName() method was throwing a NullReferenceException. I put in a null check to stop it. Also post a comment to the WorkItem noting the Changeset. Hopefully someday there will be a mechanism to automatically create a Changeset link that allows you to see the comments and even the changed files.
  • Work Item management: Please don't hold back on creating work items. Something broken? Create a Work Item. Do you have an idea for a new feature? Create a Work Item. If someone posts something in the discussion forum that is actually a bug use the handy "Convert to Work Item" link. Same thing goes if someone is discussing a possible new feature and you feel it is an appropriate feature to implement either now or in the distant future. If you decide you want to work a work item only assign it to yourself if you are going to work on it exclusively. Otherwise note which parts you are working on so that we don't have duplicated efforts. When you have committed code that satisfies the work item completely set the status to Fixed (do not close). This allows the team to review the changes. Only when the assigned release# has been released will I close all Work Items for that release. This does not however apply to issues that don't involve code changes. Please close these once they have been completed.
  • Coding Style: Er, I'm having trouble finding the right one... It's basically the Microsoft issued guidelines but private member variables are prefixed with underscores.

Last edited Feb 2, 2007 at 4:13 PM by ChrisRickard, version 4


No comments yet.