-
Notifications
You must be signed in to change notification settings - Fork 0
Guide to the OMA Process on GitHub
This page provides some guidance on ways that the OMA process and procedures can be supported on GitHub. This guide uses some new terms to refer to OMA work items, e.g. as "projects" and the home page for each work item (project) being a "repository". These are the conventional terms used by GitHub users and OMA should adopt them.
A repository called "Work Items" is created. Its readme will outline the procedures for work item creation, review, approval, and status reporting. Its wiki will contain one entry for each work item in the categories:
- New Work Items
- Current Work Items
- Closed Work Items
Per a template to be provided, work item wiki entries will created (named WIDnnnn "long name" ("short name")) contain all the essential information currently in the slide decks used by OMA, except that the only graphics needed are those illustrating the intended work.
Work item reviews and comment resolutions will be documented using the issues tool for the Work Items repository. An issue will be created titled "(short name) Work Item Review", and all comments/resolutions (in general or specific terms) provided in response.
Once the WID is approved, a repository will be created for the work item, and the WID published on a wiki page under the work item, either as a slide document or wiki page (preferred). See GotAPI for an example.
A work item status wiki page will also be created, and contain key information (current, actual, proposed dates etc) from the current WISPR tool. See GotAPI for an example.
Projects may include various document types, e.g. specifications, presentations, media (illustrations, video), code, and arbitrary supplemental information. These will be organized in folders under the project, e.g. per the proposal:
| Folder | Description | Folder Naming Convention |
|---|---|---|
| Contributions | General contributions to the project | Files are named per the current OMA document convention (name reservation system is TBD) |
| ER | Combined Enabler Release Specification | Simply "ER" (1) |
| ERELD | Enabler Release Description | Simply "ERELD" (1) |
| RD | Requirement Document | Simply "RD" (1) |
| AD | Architecture Document | Simply "AD" (1) |
| TS | Technical Specification | "TS"-(short name), where "short name" reflects the scope of the TS |
| ETR | Enabler Test Requirements | Simply "ETR" (1) |
| ETS | Enabler Test Requirements | Simply "ETS" or "ETS"-(short name) |
| SUP | Supplementary documents | Simply "SUP". May be broken out into specialized folders per document type |
| etc |
Notes: (1) Only one document of this type is expected per project.
The issues tool will be used to initiated discussions on issues and change requests (CRs), named similarly to the current document-based CR convention (name reservation system is TBD). CRs can:
- contain a short description of the desired change directly in the issue post
- reference a CR document posted to a "CR" subfolder of the document under review (name reservation system is TBD)
- be issued as pull requests from cloned repositories
Open issue: how to avoid needing to clone the entire project repository (with all documents), just to issue pull-request based CRs).
The issues tool will be used to initiate and record the progress of document reviews.