Page History

§1a+ $1b+ $1c + §1d: RICP development is done by teams, each with their own PO (Product owner). §1a: Each team has its own scrum (not kanban) backlog which is generated based on filter that is based on a mapping of components to that team. This mapping of  component-to-team is visible in the RICP repository list page. §1b: For this to work - by convention - we mark each JIRA item only exactly belonging to one component; the primary component. We do not have teams as "JIRA components" - even if that might come in handy for items that are not mapped to a component yet (the PTL can create components in JIRA quite quickly). Two exceptions: the component ricp-integration for team T6 and the component ricp-e2e for team T7. §1c: In board views you see only epics mapped to a component of your team. User stories of your team that are mapped to epics of other teams are only visible if you click on "all issues" in the epic selection box. §1d ...

...

DEPRECATED (curious? -> check old text from wiki page history) During 2019 and 2020 we used team-specific JIRA Scrum boards with RICP component-based assignment to teams. We do not use this concept anymore and instead do as per §1e.

§1e: $1e: Subteams are typically small (1-3 20 developers) and do not focus on specific RICP components. Therefore they do not have their own scrum backlog, but rather the items are managed (JIRA states, subitem management) by the "owning" team (T1..T8subteam-s, subteam-h, subteam-n, subteam-a) . We mark the fact that a subteam has picked up a JIRA item by marking the item as assigned to a person from that team and at the same time we also add one of the subteam labels (subteam-s1s, subteam-s2, subteam-h1h) to the item.  Subteam members may use the filters in §1d §7.5 and §7.6 for listing what they are currently planned to work on.

§2: Backlog DEPRECATED (curious? -> check old text from wiki page history) No backlog sprint planning is done for JIRA (user) stories. Stories are linked to higher-level JIRA Epics (which from team planning perspective are not particularly interesting) via the "Epic link" property of a story. Epics can be either project specific, e.g., a RICP epic, or RSAC-defined (O-RAN-SC's Requirement steering and architecture committee) epics that touch many subprojects. Epics are primarily for very high level release planning and not that relevant in sprint planning., i.e., we do not plan finer than per-release

§3: To access JIRA or to be assigned JIRA items you must have a free LF (Linux Foundation) account and you must have logged in at least once into LF's JIRA. Please ask your team mates to do so.

§4: The workflow is generally (a) TO DO → (b) selected for development → (c) in progress → (d) in review → (e) done. The state "in review" is a bit badly named, but it is optional for teams to use and it describes the situation that a development team considers the item as done, but the PO (product owner or similar representative/delegate of the team) has not formally accepted it yet. As of JanSep-2020 this 20201this state only is not used by any team T4 (Avinoam)anymore. JIRA also has a name for each state transition under the "workflow context menu) as follows: Assign near-term schedule (TO DO→selected for development), start work (selected for development→in progress), done, but waiting for approval (in progress → in review), approved (in review → done), done and no further approval (in progress → done). Again, note that the "grayed out" state transitions as of Jan-2020 are only Sep-2021 is not used by team T4 (Avinoam). For all other teams a JIRA items go through creation and three transitions passing through four statesany team anymore, i.e., JIRA items generally go from creation through three transitions before ending in "done" state.

§5.1: JIRA has a concept of releases (aka versions). We use this naming convention: Bronze-R3, Bronze-R4these names G, F, E, Dawn, Cherry-R5R6, Cherry-R6. R3 and R4 are the first and second half of Bronze. R5. A release ZZZ_future is used to indicate items that are not yet planned to be worked on any time soon. A release ZZZ_never is used to indicate items we never plan to work on (Jira's Resolution field (with the state "won't do") is not used for anything). This way at least (new) epics that do not have any release version as "fix version", must be analyzed still on when they are to be worked on.

...

§5.3: Complete items (for parts of items see §5.2) that were originally planned for a release X, but were not even started yet simply (1) mark with the label ""movedoutofbronzeR4" (related "movedoutofbronzeR4" filter) and (2) move to the next release by removing the old value in the "fix version" field and replace it with the new plan, i.e., the label for X+1 if  that's very likely the plan, or ZZZ_future if it is not yet clear when the item will be picked up again.

§6: Each team creates their own 3 week We plan with the following sprints (and names) as per the naming scheme below which is aligned with the Bronze (B) and Cherry (C) timeline. P1-P3 are mapped to "release planning sprints". D1-D6 to "release development (and integration) sprints".

• RICP_T1 Sprint B.P1 (last week of previous release plus week 1 - this is exceptionally only 2 weeks),
• RICP_T1 Sprint B.P2 (week 2-4),
• RICP_T1 Sprint B.P3 (week 5-7),
• RICP_T1 Sprint B.D1 (week 8-10), Bronze-R4: Sprint B.D1 (Feb-03 ... Feb-23)
• RICP_T1 Sprint B.D2 (week 11-13) Bronze-R4: Sprint B.D2 (Feb-24 ... Mar-15)
• RICP_T1 Sprint B.D3 (week 14-16), Bronze-R4: Sprint B.D3 (Mar-16 ... Apr-5)
• RICP_T1 Sprint B.D4 (week 17-19), Bronze-R4: Sprint B.D4 (Apr-6 ... Apr-26)
• RICP_T1 Sprint B.D5 (week 20-22), Bronze-R4: Sprint B.D5 (Apr-27 ... May-17)
• RICP_T1 Sprint B.D6 (week 23-25), Cherry-R5: Sprint B.D6 (May-18 ... Jun-7)
• RICP_T1 Sprint C.P1 (last week of previous release plus week 1 - this is exceptionally only 2 weeks), Cherry-R5: Sprint C.P1  - EXCEPTION in 2020 (3 weeks): Jun-8 ... Jun-28
• RICP_T1 Sprint C.P2 (week 2-4), Cherry-R5: Sprint C.P2 (Jun-29 ... Jul-19)
• RICP_T1 Sprint C.P3 (week 5-7), Cherry-R5: Sprint C.P3 (Jul-20 ...  Aug-9)
• RICP_T1 Sprint C.D1 (week 8-10), Cherry-R5: Sprint C.D1 (Aug-10 ... Aug-30) *exceptionally added to Cherry-R5 (2020) thereby shortening Cherry-R6

§7: Some useful direct links to Jira:

Releases):

• Sprint J release dev sprint 1: Feb-19 to Mar-10
• Sprint J release dev sprint 2: Mar-11 to Mar-31
• Sprint J release dev sprint 3: Apr-1 to Apr-21
• Sprint J release dev sprint 4: Apr-22 to May-12 (last planned development sprint)
• Sprint J release dev sprint 5: May-13 to Jun-2 (only for unplanned last-minute development items)
• Sprint I release dev sprint 1: Aug-21 to Sep-10
• Sprint I release dev sprint 2: Sep-11 to Oct-1
• Sprint I release dev sprint 3: Oct-2 to Oct-22
• Sprint I release dev sprint 4: Oct-23 to Nov-12 (last planned development sprint)
• Sprint I release dev sprint 5: Nov-13 to Dec-3 (only for unplanned last-minute development items)

§7: Some useful direct links to Jira:

1. Filter All RICP items: E release only
   1. committed (90% sure) and tentative (90...30% sure) items: subteam-n, subteam-h, subteam-s, subteam-a and all teams.
      
   2. committed items only: all teams (committed)
2. Filter All RICP items: F release only
   1. committed (90% sure) and tentative (90...30% sure) items: subteam-n, subteam-h, subteam-s, subteam-utfpr, subteam-p and all teams.
      
   2. committed items only: all teams (committed)
   3. items that are known to require work, but are currently not in F release: link
3. Filter All RICP items: G release only
   1. committed (90% sure) and tentative (90...30% sure) items: subteam-n, subteam-h, subteam-s, subteam-utfpr, subteam-p, subteam-c and all teams.
   2. committed items only: all teams (committed)
   3. items that are known to require work, but are currently not in G release: link
4. Filter All RICP items: H release only
   1. committed (90% sure) and tentative (90...30% sure) items: subteam-n, subteam-h, subteam-p, subteam-s, subteam-utfpr, subteam-c, subteam-ag, subteam-cg 
      
   2. committed items only: all teams (committed) and all teams (committed + tentative).
      
   3. items that are known to require work, but are currently not in H release: link
5. Filter All RICP items: I release only
   1. committed (90% sure) and tentative (90...30% sure) items: subteam-n, subteam-h, subteam-p, subteam-s, subteam-utfpr, subteam-ag, subteam-cg, subteam-r, subteam-gs
      
   2. committed items only: all teams (committed) and all teams (committed + tentative).
      
   3. items that are known to require work, but are currently not in I release: link
6. Filter All RICP items: J release only
   1. committed (90% sure) and tentative (90...30% sure) items: subteam-n (Nokia), subteam-h (HCL) , subteam-p (Parallel Wireless) , subteam-s (Samsung), subteam-utfpr (University UTFPR), subteam-ag (Abhijit Gadgil), subteam-cg (CapGemini, subteam-r (Rakuten), subteam-gs (gslab.com)
      
   2. committed items only: all teams (committed) and all teams (committed + tentative).
      
   3. items that are known to require work, but are currently not in J release: link
7. Filter: All items mapped to sprint "Sprint B.P1" : filter10308 (adapt filter string (13,14,...) to point to sprint names for the sprint your are interested in. Note you need to list seven sprints, as each team (RICP_T1..7) has its own sprint).
   
8. Filter: All items mapped to release Bronze mapped to your team: use filters from §1 and add this to the search filter: "AND fixVersion in (Bronze-R3,Bronze-R4)" before the "ORDER" part of the filter.
   
9. Filter: All RICP items (epics, user stories, ...) mapped to release Bronze: filter10400 and Bronze-epics only (i.e. no user stories or others) filter10401 and Bronze-R4-epics only filter10509.
   
10. Filter: All RICP items (epics, user stories, ...) mapped to release Cherry: filter10601 and Cherry-epics only (i.e. no user stories or others) filter10602 and Cherry-R5-epics only filter10603 (incl. stretch goals) filter10605 (excl. stretch goals) and Cherry-R6-epics only filter10604
11. Filter: All RICP items that are not yet done: all = epics only + non-epics.
12. Test Epic and test user story Use RICP test epic RIC-42 and the linked test user story RIC-43 to experiment with JIRA. Right now these are mapped to team/board for team T1: board #16 .
13. All Epics (not only RICP): link
14. Search for a word in any of the RICP items: link

...

To delete an item please add the string "DELETE_ME" (with an underscore in the middle) into the summary of the item. The RICP PTL (Thoralf Czichy ) will delete such items every once in a while using this filter: filter10510. Additionally, you may also send an e-mail to the PTL asking for deletion of an item.

§9: Security bugs (see also Tools (mailing list, JIRA, Gerrit))

We currently expect all security bugs to be reported publicly as JIRA issue of type "Security Bug". Other then classified as type "Security Bug", they are managed in the JIRA tool the same way as other bugs.You can use this filter (requires login) to view all security bugs: https://jira.o-ran-sc.org/issues/?filter=10701 (same filter without login: link)