CM: The Next Generation of SCM Standards

the head.  It's a variation of a standard offering.  And indeed, there can be dozens of variations.  Option is a good word, but it is really a selection of several Options that determine a Variant.  So a French Military Variant is created by selecting the Military Option and the French Option.  [Make your life easier by deferring as many Option selections as possible to Run-Time, reducing the number of Variant deliverables.]

My Vote: Variant

Problem
Problem Report, Problem, Defect, Bug, Issue, Non-Conformance.  When a problem is found with the way software behaves, there are many different words we use to identify it.  Really, what we have is either an error in the original specification, or a non-conformance with that specification.  Non-conformance is fairly accurate, though a bit of a mouthful, and doesn't deal with specification errors.  Issue is used strongly in the military, and outside of it too.  However, "issue" does not necessarily denote a problem with the product.  For example, consider a "pricing" issue or a "support" issue.  It's more a statement that the customer is not satisfied.  I like the term "Problem Report" but it's a mouthful, and can be confused with a Report about Problems as opposed to a statement of problem.  Bug is short and historical, but not very friendly once you move outside of the developer/tester domain.  Problem, as in Problem Tracking, seems to have a lot of support, and Defect as well, but to a lesser extent.

My Vote: Problem, Defect, Bug (in that order)

Activity
Feature, Activity, Task, ToDo Item.  What do we call the things we do to a product that are different than fixing conformance to the original specification?   They're features, right?  Well, usually. Sometimes they're refactoring activities.  Sometimes they're "code instrumenting".  Sometimes they're creating basic architectural components upon which features will be built.  Feature is a good term for what the end user will see, and it is an important and useful term.  ToDo Item is more general, but perhaps too much of a bookkeeping item.  But perhaps Task or Activity fit better.  

I have a bias here.  I like these two terms because, unlike software problems which are too numerous and usually too simple to fix to spend time planning for each one, tasks and activities require some definite specification and expected effort.  In other words, they fall well into the Project Management and Product Management domains.  The former has to deal with scheduling/tracking the work, whether in an Agile or Traditional manner, while the latter has to deal with what is being completed for the next release(s) of the product.  So I think it's important to tie these into the CM world to ensure we don't have different Project Management and CM databases, processes and efforts.

My Vote: Activity,Task

Request
Request, Change Request, Issue, Feature Request.  So what about a customer issue?  How do we name it?  What happens when the customer needs something done?  We track it as an issue, or a request.  Sometimes it's a change to the requirements, but it is the impetus for such change that we're considering here.  

There are a few things to keep in mind here. One, the request is sometimes for a feature, sometimes for a problem, and the customer doesn't always know which.  Two, the same request can come from multiple customers.  Three, the customer may be an internal user or even a developer.  Four, the request does not always require the vendor to do something, other than perhaps pointing to the correct page of the documentation.  

Issue is a good word, but it implies