|
|
Child Level:
|
Managing InRoads PreferencesFile Masters ManagementPrimary Data Clients
Each primary data client is probably best managed by a single lead, probably one per department. Differing symbologies can be managed by making sure that Symbology is defined within commands only by generic Named Symbologies (deviations or managed within the Named Symbologies list). Named Symbology lists can be maintained separately by the separate client leads. Command Preferences are where things can get tricky. They are best managed by department or client leads. The primary question is the degree to which to try to consolidate clients into single files. Across departments this becomes complicated and has "shared responsibility" or "interest bias," both of which have their issues. I'm thinking that we can have department leads manage the command preferences separately in separate files. What may help is sticking to a consistent Client prefix convention, for example:
The prefix may be a bit unwieldly for users at first, but I think it's the only way that we'll be able to maintain any longer term manageability. Client and Project Seed filesI support the users' right to write and don't believe in read-only seeds (including a single shared XIN). The trick in allowing users to mange their own XIN file is clobbering the bad mutations and managing the good mutations. (there is info below on managing good mutations). Each Project and Client Seed XIN's should be managed by a single person, probably the Department lead. Copying the Project Xin to the user's project folder should be part of the user's initial project setup. With the old INI format, I would search and clobber the user's INI file, enabling and requiring the user to managing their beneficial mutations. With the XML format, I haven't got a simple tool yet to make it really easy for them. So this part is still a bit up in the air. Hot Links
|
|