Does anyone have a best practice recommendation for managing the proliferation of custom fields? We have many (many!) projects and in an effort to gain some consistency we're enforcing strong governance against the creation of project-scoped custom fields.
Proliferation of project-scoped custom fields makes aggregate analysis of data difficult and risks the hiding of relevant information when work items are moved for any reason from one project to another. It also makes it difficult for team members to move from one project to another. On the other hand, having too many values in one custom field introduces ambiguity and errors, and make the user experience more difficult. As a subscription administrator I reject most requests for custom fields in favor of tags, but we have some custom dropdown list fields with over 20 choices due to the need to accommodate many projects.
I didn't see anything specific to this (except for a very good idea about setting default values) in Agile Central Idea Manager so I created one at https://ideas.rallydev.com/ideas/D3894. If you have relevant experiences or recommendations that you'd like to share then I'd love to hear about them, or if you think that this is a good idea then upvotes in Idea Manager would be appreciated!
@CA Agile Central Subscription Admins