CM: The Next Generation of SCM Standards

The high level standards are primarily process standards:  Make sure you identify every component, manage and control change, have a means of tracking the state of your CM artifacts and ensure that you can prove that you build is what was asked for.  These are important but very high level criteria.  The problem has been that, as we look deeper, there is greater divergence - there are various basic capabilities without guidance.

For example, it's fine for an SCM standard to say that all revisions of a file, once registered in a CMDB, must be available for all time.  And it's fine to say that parallel branches of revisions must be supported.  But these capabilities, without guidance, can lead to poorer SCM.  Just look at those projects where branching and/or labeling have gotten out of control.

Now one of the more frustrating things I find is the lack of a basic standard for terminology.  What do you mean by "status accounting", or even worse, is it a "change package, an update, a changeset or a change"?  So maybe it's time to start nailing things down a bit.  Of course if we try to do this, we're in for a real battle - that's just the nature of standards.

Perhaps there are some of you who would like to add your opinions so that we can somehow march toward some better standards over time.  I'm not going to try to bite off the whole standards issue in one article.  It's just too big.

Terminology
So perhaps, to simplify the process of the SCM Process standards discussion, I'll focus on terminology.  I hate to leave behind the "push the industry forward" part, but for now I will, while addressing that in a future discussion on standards.

Terminology is such a crucial part of a standard and often the most "visible" component.  Lack of consistent terminology can cause confusion even with the best standards.  Even if the standards clearly define what the terms mean, if the definitons are unnatural or divisive, the standard, clear as it might be, might lead to overall confusion and rejection.

Now terminology itself is a large domain.  There are "things" (Changes, Revisions, etc.) and there are "actions" (Identify, Audit, Build, Release, etc.).  Some even have the same name (Build vs Build, Release vs. Release).  As actions tend to act on things, I'll focus first on things.

Below I present a bunch of terms used in SCM.  I'm sure I don't have all of the terms used in all processes and tools around the world, but hopefully I've captured a number of them.  In some cases, term Name Standardization is required, in others term Definition Standarization is required.  I selected my preferences, and, more importantly, I've given my reasons for these selections.  You may have different preferences and better reasons.  Great!  But let's hear from you.

Name Standardization
There are a lot of terms used to describe basic concepts.  We need to drastically reduce this set of terms (not concepts).

• Changeset, Update, Change, Change Package
• Revision, Version
• Variant, Version, Generic, Option.  
• Problem, Defect, Bug, Issue, Problem Report, Non-Conformance
• Feature, Activity, Task, ToDo Item
• Request, Change Request, Issue, Feature Request.  
• Item, Artifact, Object, File, Document, Datum (Data), Record
• Iteration, Cycle, Internal Release, LifeCycle
• Stream, Development Stream, Release Stream, Release Branch, MainLine, Product Branch
• Configuration, Alignment, Baseline
• Build, Build Record, Build Notice, BOM
• Context, Views, Context Views.  
• Service Pack, Increment, Update Package, Change Supplement

Definition Standardization

• Product Requirement vs Customer Requirement vs Design Requirement
• Product vs Project vs IDE Project
• Process Flow vs. Work Flow vs. State Flow