What is a Work Item
The Work programme and technical coordination are defined in the 3GPP Working Procedures (Section G):
-Article 38: Work Items
-Article 39: Work Item creation
-Article 40: Work Item adoption
-Article 41: Work Item stopping
-Article 42: Technical co-ordination
From the WorkPlan perspective, a Work Item (WI) is fully characterized by the following set of attributes:
- Unique ID;
- Release (based on the completion date);
- Code / Acronym (Find a complete list of work item codes here);
- Responsible WG or TSG;
- % completed;
- Impacted TSs and TRs;
- Hyperlink to the most recent Work Item Description (WID) document;
- Hyperlink to the previous history of WID documents;
- Date of creation of WI record;
- Most recent modification date;
- Remarks (free field);
- Early Implementation flag (see 3GPP TR 21.900);
- In the case of work terminated prior to completion, the TSG meeting at which work was stopped.
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.
Guidance for the allocation of codes to Work Items:
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.
Avoid hyphens and underscores
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_".
Avoiding Release information in WI name
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".