General Guidelines for

Pronto’s / Gitlab tickets

- Discussion outcomes from VSM
workshop conducted at NOKIA
Bangalore (Aug 2023)

Contents

General Guidelines for

Pronto’s / Gitlab tickets
- Discussion outcomes from VSM
workshop conducted at NOKIA
Bangalore (Aug 2023)
...1
General Guidelines for Pronto’s / Gitlab tickets....................................................................................2
For action items on team members, look at all the points which are marked as Team member:.....2
For action items on LPO’s, look at all the points which are marked as LPO:......................................2
For action items on FCB team, look at all the points which are marked as FCB:...............................2
1. Log requests:.................................................................................................................................2
2. LGF request:...................................................................................................................................2
3. TSN request:..................................................................................................................................3
4. Closure of Gitlab tickets:................................................................................................................3
5. Hot-fix preparation/ verification to be done parallelly..................................................................3
6. How to determine when a hotfix/ PP has to be released –...........................................................3
7. Approval for LGF/ TSN/ PP/ Hot fix:...............................................................................................3
8. Regarding changing the priority of Gitlab tickets:..........................................................................3
9. Regarding Correction Form creation for all applications:..............................................................4
10. Minor OEM upgrades regression testing...................................................................................4
11. Regarding re-opening a PR:.......................................................................................................4
12. OEM escalation handling with support from NOKIA:.................................................................5
Nokia Contacts:..............................................................................................................................5
13. Appendix: Golden Standard of Fault Report..............................................................................6
14. PR transfer process................................................................................................................6

General Guidelines for Pronto’s / Gitlab tickets

Some of the points highlighted during the VSM workshop, to identify the time-waster activities
which occurred during the lifecycle of long runner pronto tickets. Some actions are being planned as
part of each of these activities listed below.

For action items on team members, look at all the points which are marked as Team
member:
For action items on LPO’s, look at all the points which are marked as LPO:
For action items on FCB team, look at all the points which are marked as FCB:

1. Log requests:
Avoid too much ping-pong’s between CARE team and R&D for request of logs from several
teams (1 after another)
Actions taken: Already we have started having architect meetings twice weekly which focuses
on - LR critical, management escalation, fault escalation cases.
New Action: LPO: First level, LPO's to keep a watch. Take it to architect forum if there is a
contention between teams at initial stages only and get it resolved.

2. LGF request:
If CARE team requests for any LGF, then we need to check with the
Authority (like CA architects) and discuss whether LGF is required or
updates to upgrade documentation can be done.
New Action: Team member: Get technical agreement with internal CA architect, then NOKIA
CA architect, Mohan. Once we agree on that, go to Artur/ Lori for approval.
3. TSN request:
In case a TSN is planned, then prior information to all stakeholders like reviewers/ testers be
informed in advance if you need reviews/ testing to be done for such cases.
New Action: Team member: TSN should go through cycle of review (Internal architects,
ProveIT/ test Architects, CA architects, Mohan). ProveIT approval should be taken from Mona/
Jaison if ProveIT could not be involved.
-- TSN to be tested by ProveIT. All cases.
-- Advance info to be provided to ProveIT teams to accommodate such testing requests.

4. Closure of Gitlab tickets:

When to close a GitLab ticket?
New Action: Team member:
-- Educate team members that ticket can be closed when it becomes a
Pronto. Or when a timeline by when the fix would be provided to
customer.
LPO:
-- Can be closed at LPO level after 2-3 reminders to CARE team that it will
be closed since solution is provided. Reach out to Ashish / Murthi, then
only to Sajal.
FCB: - Already going on
-- Review of LR tickets > 15 days from CG governance team to closely monitor why it's not
closed.

5. Hot-fix preparation/ verification to be done parallelly.

Preparation of Hot-fix and testing – In cases where the confidence is high, the
preparation of hotfix and it’s documentation etc. be done as a parallel activity while the
hot-fix verification is being carried out by other test teams.
New action: LPO: Team member: LPO's to cascade this info to team members.

6. How to determine when a hotfix/ PP has to be released –

1. If it is a common problem across for all customers – better to go for PP.
2. If it is a problem occurred only for a single customer – hotfix can be provided.
New action: Team member: LPO: LPO to cascade this info to team as a general guideline.

7. Approval for LGF/ TSN/ PP/ Hot fix:

New action: Team member: Need to get approval from CSE folks (Artur, Lori) for CARE team
requests for LGF/ TSN/ PP/ Hotfix etc.
8. Regarding changing the priority of Gitlab tickets:
The priority of the Gitlab tickets can be negotiated to lower priority, in
cases of issues which are low impact to customer. – Gitlab Triage
meeting conducted by Lakshmi G can help with this.
-- New action: LPO: LPO to take it up in meeting for reduction in genuine cases

9. Regarding Correction Form creation for all applications:

Whenever the fix has to be provided to one app, there is a need to evaluate if the same fix
should be provided across all applications?
New Action: Team Member: LPO: Confluence page created where all APP teams will
come back with a feedback whether their APP has been impacted too. Then, we create CF
for different teams.
New action: Team member: Point to be discussed here is whether to have 1 CF with
modification sets from all teams OR do we need to use multiple CF's for each team? – Check
with FCB governance team

10. Minor OEM upgrades regression testing

New Action: Team member: Forward info to all teams that wherever PLATFORM is doing
changes (minor OEM upgrades etc), all component teams should own the analysis and finish
in deadline. If they don't, escalation to CA architect's and release managers. If any defect
leaks later, that defect will be owned by the concerned team and not the PLATFORM team -
is the AGREEMENT with NOKIA. Confluence page closure should be done before releasing
the fix from our side. If need be escalate to 1st level CA's, then release managers that teams
are not responding.

11. Regarding re-opening a PR:

New action: Team member: Team
needs to be aware of the new
process that once a Pronto closed and if issue reproduced after
14 days, a new PR must be opened. PR re-opening not allowed
after 14 days’ time limit.

NOTE: One exception case below for Customer PR’s where the above point does not apply.
 12. OEM escalation handling with support from NOKIA:
Having an open discussion with NOKIA side OEM escalation managers may help to resolve
some issues we face while directly interacting with the 3rd party OEM’s. Sometimes it may
not be OEM issue also, but we may need support from them in some cases.
New action: LPO: Talk to SPOCs from NOKIA side for each OEM. All LPO's to attend Weekly
PO-PM sync weekly meeting. It is mandated already that LPO’s join the meeting on need
basis and escalate on need basis.
vSphere, IBM, Keycloak , Oracle DB, JRE - Anand Durairaj & other specific contacts
mentioned in below table

NOTE: In case, further escalation is needed to support the issue related to OEM, please involve
NOKIA as next Escalation level. Prior to initiating Management escalation through Nokia, the
following points must be met:

1. Provide a summary of the problem's impact, including the ticket number, Priority and the
specific pain points (e.g., no response, slow response, non-functioning fix, etc.).
2. Conduct an analysis by the R&D team to confirm that the issue does not originate from the
product software itself.
3. Share the current status of the ongoing Supplier escalation, including a brief history of Supplier
Escalation efforts towards the OEM Vendor.
4. Nominate a technical expert (from the supplier) to clarify vendor support inquiries.
5. Share the Name and Title of the individual from the Supplier who has already initiated
management escalation towards the OEM Vendor.
6. Individual name responsible for arranging the meeting and distributing the Meeting Minutes
(MoM) following the discussion with the OEM regarding Escalation.

Nokia Contacts:

OEM NM LT member for

Management Escalation
Vendor Management escalation
Celtius Janne Heinonen janne.heinonen@nokia.com
 Citrix Kiran VM kiran.vm@nokia.com
CommVaul
Kashif Khan kashif.khan@nokia.com
t
DELL EMC Kashif Khan kashif.khan@nokia.com
Meenakshisundaram
HPE meenakshisundaram.sivasubramaniam@nokia.com
Sivasubramaniam
IBM Rahul Varma rahul.varma@nokia.com
Microsoft Kiran VM kiran.vm@nokia.com
Oracle Miia Forssell miia.forssell@nokia.com
Red Hat Rajesh P rajesh.p@nokia.com
VMware Markku Lukkarinen markku.lukkarinen@nokia.com

13. Appendix: Golden Standard of Fault Report

For your reference
Golden Standard of Fault Report - Home (sharepoint.com)

14. PR transfer process