3 From an idea to an approved version

3.1 Nothing starts until somebody files a work item

A 3GPP specification does not begin with a draft. It begins with a proposal to do the work at all.

An Individual Member, or a group of them, submits a Work Item Description sheet to the relevant TSG or working group. For new services and features, the TSG responsible for services and system aspects is the one to go to §6.1.

The working group studies and refines the sheet and passes it up, and the TSG decides. Until that decision, no substantial work starts in the working group §6.1.

"Work item" is an umbrella word, and knowing what it covers saves a lot of confusion in a meeting report.

3.2 Feature, building block, work task

Those four names are a hierarchy, and the document explains each one in the same clause §6.0.2.

A study item comes first when nobody yet knows whether the thing is feasible. It produces a Technical Report. If the result is positive, one or more feature work items follow §6.0.2.

A feature is new or substantially enhanced functionality that adds value to the existing system. The document says its description need not be technically precise, but should answer the question: what do I get for my money? §6.0.2

A building block is a slice of a feature — a coherent set of technical function that would normally live in one system element. A work task is a slice of a building block, small enough that somebody can estimate how long it will take §6.0.2.

That last point is the reason the hierarchy exists at all. Schedules are estimated at the bottom and added upwards, so a feature's finish date is built out of its work tasks rather than guessed §6.0.2.

Whatever its size, every work item needs four things: a precise scope, an estimated schedule, a named rapporteur to manage it, and at least four Member Organizations willing to work on it §6.0.2.

3.3 The rapporteur, and version 0.0.0

A new specification is created inside a group, and a rapporteur is appointed at the same moment.

The rapporteur serves as editor until the document goes under change control, hands a clean copy to the Support Team for tidying before approval, reviews every change request to it before the working group agrees, and acts as the person other groups ask when they do not understand it §4.1.2.

Meanwhile the Support Team allocates the specification number as soon as the title and scope are stable, and enters the document into the status list §4.1.1.

3.4 The three stages

Where it fits, the work follows a three-stage method the document borrows from the ITU §4.1:

• Stage 1 is the service described from the user's side.
• Stage 2 is how the network functions are organised to deliver it.
• Stage 3 is the switching and signalling detail.

Two informal extras hang off the ends. A feasibility study done before stage 1 is sometimes called stage 0, and the test specifications that follow stage 3 a stage 4 §4.1.

This is why a question can be answered "correctly" and still be answered in the wrong document. How a field is encoded is a stage 3 question, and quoting a stage 2 document at it proves nothing.

3.5 Sixty per cent, eighty per cent, and the jump

Now the version number does the talking. The first digit of x.y.z carries the state of the document §4.0A.

• 0.y.z — a draft, circulating inside the group.
• 1.y.z — presented to the TSG for information. The responsible group estimates the document to be at least 60% stable.
• 2.y.z — presented to the TSG for approval, at roughly 80% stable.
• 3 or greater — approved and under change control, and the digit is now the release number.

The document is honest that the percentages are subjective and the decision rests with the responsible group §4.0A.

The last step is the one that surprises people.

3.6 Tracking whether it will make it

A work item's state is recorded in the work plan throughout its life, and takes one of four values §6.5:

• Not TSG approved — a draft work item nobody has adopted yet.
• Work in progress — adopted, and less than 100% complete.
• Frozen — complete; only essential changes may use this work item code.
• Stopped — abandoned unfinished. Changes already approved under its code stay in the specifications unless somebody writes changes to take them out.

From version x.0.0 onwards, nobody edits the text directly ever again. Every technical change is a formal proposal on a form, which is The change request and the release.