What is a Work Item

Although the "Unique_ID" numeric value is essential for managing the work plan and the Specs, a pure number is not very memorable. Therefore, all high level Work Items (and many lower level WIs) have a textual code or acronym chosen either by the WI proponents or by the Support Team. It is this code which must be used on Change Request cover sheets, and anywhere else where a human-oriented brief identification of a Work Item is required.

All top-level WIs need to be assigned such a code; it will be convenient for most building block level WIs also to have a unique code; it may sometimes be useful for lower level WIs also to have their own codes: it depends on the granularity with which a Change Request (etc) needs to be associated with a particular WI. Often, a CR need only be associated with a building block or even with a feature, so subordinate WIs do not need their own codes.

The code should be an abbreviation of the full title of the work item, insofar as that is possible in a reasonable number of characters.

The code should not contain punctuation (except for decimal separators where necessary) other than hyphens to separate its fields (as described below). The code should not contain any characters other than:

• letters (a to z) without accents or other accidents
• numerals (0 to 9).

The code should be separated into up to three fields, depending on the hierarchical level of the work item:

• 1st field: Feature (or Study Item)
• 2nd field: Building Block
• 3rd field: Work task

with the fields separated by hyphens. Thus a Feature will have only one field; a Building Block will have a code composed of the code of its parent Feature followed by a hyphen followed by a field unique to that Building Block; a Work Task will have a code composed of the code of its parent Building Block (two fields) followed by a hyphen followed by a field unique to that Work Task.

Thus the hierarchical level of a WI can be determined by looking at its code: Features and Study Items have single text strings with no hyphens. Building Blocks have codes separated into two fields with a hyphen; and Work Tasks have codes separated into three fields with two hypens.

Because of the danger of confusing hyphens and underscores, it is recommended to avoid the use of underscores in WI codes except as proposed at the end of this paragraph. Work item codes are case-agnostic, though intelligibility may be improved by conventional mix of upper and lower case letters. For example, the code for a work item having the title "LTE radio considerations for mission-critical applications" might have the code LteRadMC which is easier to interpret than LTERADMC and takes fewer characters than LTE_RAD_MC. For ease of manipulation, it is recommended that WI codes be limited to no more than seven characters per field, though it is recognized that there will be cases where a longer string is desirable or necessary. The top level code for a Study Item should begin with "FS_". 

In principle, at the time a new Feature or Study Item is proposed, it is not known which Release the results will appear in. If work progresses faster than originally intended, it may be an earlier Release; and if slower, a later Release. Therefore, it is strongly advised not to include any reference to a Release in a work item name or acronym. Where work is conducted over a long period of time, inevitably spanning several Releases, the preferred method is to have two or more top-level work items distinguished by "phases", i.e. with the titles and acronymns of the work items showing "phase 1", "phase 2", etc. The "phase" is disassociated from a specific Release. Thus phase 1 might be completed in Release N but phase 2 might not be ready until Release N+3.

For a new work item, the author of the work item description (WID) document should propose a work item code or acronym, following the above guidlines. This code is provisional and could be modified in the course of the WID approval process at TSG plenary level. When the code has been confirmed, if the WID is updated, the word "Proposed" should be deleted from the line "Proposed Acronym".