# Introduction
The goal of this document is to define and outline all the processes and procedures that the Protocol Team is conducting.

Just like any other product, it's difficult to in details define all the procedures that are happening, but great attention will be paid to make sure that the most important ones are defined here and that the less impactful ones are defined either in another document or verbally.

It's important to mention that this document is still in the develop phase and it's expected to contain grammatical and logical mistakes. Several iterations will be done until this is as perfect as it can get and at that point an RFC will be created.

## Term Definition and Terminology
This document contain some business jargon that may or may not be interpreted in different ways. This section will clearly define those terms so that there is no room for miscommunication.

**What is SOP?**
> A Standard Operating Procedure (SOP) is a formal document of a procedure or routine activity in an organisation. It provides general information about the activity and focuses on specifying details such as the people and resources needed to complete it

> Standard operating procedures outline:
> I. What the activity is
> II. Who performs the activity
> III. When the activity is performed

**What is included in an SOP?**
>I. A title that clearly identifies the procedure or activity
>II. The procedure, which includes its purpose, scope, requirements, and summary of its steps
>III. A checklist of activities for quality control and quality assurance

[SOP Source](https://venngage.com/blog/work-instruction-vs-sop/)

**What is RCA?**
> A root cause is defined as a factor that caused a nonconformance and should be permanently eliminated through process improvement. The root cause is the core issue—the highest-level cause—that sets in motion the entire cause-and-effect reaction that ultimately leads to the problem(s).

[RCA Source](https://asq.org/quality-resources/root-cause-analysis)

**What is CAPA?**
> CAPA is the abbreviation for corrective and preventive actions. The term refers to the improvements to an organisation’s processes to mitigate undesirable situations like product nonconformities and is typically used in connection with quality assurance.

> CAPA can provide a structure for organisations to follow to find the cause of a problem, solve it, and identify ways to prevent the problem from occurring in the future. Thus, organisations _correct_ the issue and _prevent_ it going forward.

**What is Corrective Action (CA)?**
> Corrective action is a kind of extension to the [Root Cause Analysis (RCA)](http://pbro.io/3vUV8Ae) approach. Step 1 of CA is to identify the root cause of the issue following a report of a nonconformity. Step 2 is to eliminate the root cause to prevent the nonconformity from recurring.

**What is Preventive Action (PA)?**
> Preventive action is when you identify and remove potential sources of nonconformities before an undesirable situation has the chance to occur.

[CAPA Source](https://blog.falcony.io/en/what-is-capa)

## Key word definition
This document follows the [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt) in the definition of the following keywords:
- MUST (NOT)
- SHOULD (NOT)
- (NOT) RECOMMENDED
- MAY

## Procedure Grouping
Existing procedures can be grouped in two distinct ways: activity-wise and time-wise.

Activity-wise procedures are grouped by their activity that they are conducting. There are four main activities that are present:
- Planing Activities
- Development Activities
- Testing Activities and
- Mitigating Activities

Time-wise procedures are grouped by their conducting time. There are two phases that are present:
- Release Phase and
- Develop Phase

The next sections will define all those groupings in more details

# Planing Activities
Planing procedures are used to determine what features will be implemented in the next Develop Phase, who is going to develop them and what resources are needed to develop those features.

## Phase Planing (PP)
### Purpose
The purpose of this procedure is to determine what features will be developed in next phase.

### Scope
Mandatory personal involvement:
- CTO
- Ken
- Protocol Team Leader

Optional personal involvement:
- Protocol Team
- DevOps Team

Designated meeting leader: Ken?

### Requirements
- A list of possible features to do in the next phase

### Summary
The meeting leader complies a document with a list of possible features to do in the next phase. The features can be anything from implementing new pallets to updating existing dependencies or developing support tools.

With a document like that, a meeting is run where all the mandatory personal MUST be present and discuss which of those features will be developed and released in next phase. The optional personal MAY be present in the meeting and MAY be involved in discussions. This is regulated by the designated meeting leader.

At least one meeting MUST be conducted and if that is not enough additional ones can be done.

This procedure MUST as an output produce a document with all the mandatory(key) features are required to be developed and a list of optional ones.

### Artefacts
Input artefact: Document with a list of features that could be developed

Output artefact: Document with a list of key features that MUST be developed and a list of optional features that MAY be developed.

## Task Planing (TP)
### Purpose
The purpose of this procedure is convert features to task and to assign them to existing Protocol Team members.

### Scope
Mandatory personal involvement:
- Protocol Team

Optional personal involvement:
- DevOps Team

Designated meeting leader: Justin

### Requirements
- Document with a list of key features that MUST be developed and a list of optional features that MAY be developed.

### Summary
The designated meeting leader runs a meeting where all the Protocol Team MUST be present and the DevOps Team MAY be present.

First the key and then the optional features are looked at, defined and MUST be converted to one or more tasks.

Second those tasks are assigned to existing Protocol Team members. The process and way of assigning is up to the designated meeting leader to define.

Third and last, all taken tasks are given estimations on when they are going to be done. Those estimations are not deadlines instead they are educated guesses which may or may not be correct. The process and way of defining estimations is up to the designated meeting leader to define.

### Artefacts
Input artefact: Document with a list of key features that MUST be developed and a list of optional features that MAY be developed.

Output artefact: Github and Jira tasks with estimations and task assignees.

# Development Activities
Development procedures are used to track on-going phase tasks and general team needs.

## Grooming Session (GS)
### Purpose
The purpose of this procedure is to have a open discussion between members of the Protocol Team. There are no hard constraints on what the topics can be, but they SHOULD be good as long as they are relevant to current team needs.

### Scope
Mandatory personal involvement:
- Protocol Team

Designated meeting leader: Justin

Frequency: Two sessions per week, one session is one hour long.

### Requirements
- A list of topics (written down in Notion) to discuss.

### Summary
Before the meeting starts all the members of Protocol Team SHOULD write down their topics (in Notion) so that all team members can prepare themselves for the discussions.

The designated meeting leader is responsible for conducting the meetings and making sure that they happen. The whole protocol team SHOULD be present on those meetings.

Once the meetings starts, the designated meeting leader chooses what topic to discuss and in what order. Each discussed topic needs to be followed up with an action item that represents the next action that will be taken in order to satisfy a demand or concern. In case there was not enough time to discuss all topics or a topic is blocked then those topics will be marked as not completed and discussed in the next session.

### Artefacts
Input artefact: Notion Grooming Session document with written done topics to discuss.

Output artefact: Notion Grooming Sessions document updated with action times regarding discussed topics.

## Review Session (RS)
### Purpose
The purpose of this procedure is to have a open discussion between members of the Protocol Team about the performance, concerns and organisation-wise or structural-wise changes that have or should be made. This procedure is meant to be used as a "safe" place for developers.

### Scope
Mandatory personal involvement:
- Protocol Team

Designated meeting leader: Justin

Frequency: One session per month, one session is two hours long.

### Requirements
- Notion Review Session document

### Summary
Over time ideas on how to improve our existing procedures pile up and require to be addressed and discussed. The designated meeting leader MUST allow for those ideas (or possibly concerns) to be heard and discussed in an safe and protected space.

On those meeting, where the whole Protocol Team is RECOMMENDED be present, everyone has the right to share their constructive or destructive ideas or concerns and discuss them with the rest of the team. It's up to the designated meeting leader to decide what ideas or concerns should be addresses or ignored. Valid ideas or concerns MUST be written down in the Notion Review Session document.

The time between two sessions is used by the designated meeting leader to analyse the written down points and on the next session he MUST say if any progress has been made.

### Artefacts
Input artefact: Notion Review Session document.

Output artefact: Updated Notion Review Session document with new tasks to analyse.

# Testing Activities
Testing procedures are used to make sure that all the completed features for a phase are well understood and tested.

## Feature Presentation (FP)
### Purpose
The purpose of this procedure is to give an overview on how an feature works and how it can be tested.

### Scope
Mandatory personal involvement:
- Protocol Team
- QA Team

Designated meeting leader: Justin

### Requirements
- A list of features that are completed and ready to be included in the next release

### Summary
The designated meeting leader complies a list of all the features that are completed and ready to be included in the next release.

With the list being ready, a meeting is called where each feature is presented by the member who implemented the feature. It's important to put emphasise when presenting on how to use and how to test the feature.

After the meeting a short guide on how to test each feature MUST be written by the member who implemented the feature.

### Artefacts
Input artefact: A list of features that are completed and ready to be included in the next release.

Output artefact: Short guide on how to test each feature that will be release.

## Feature Compliance (FC)
### Purpose
The purpose of this procedure is to determine if all the features are implemented and working as intended

### Scope
Mandatory personal involvement:
- CTO
- Ken
- Protocol Team Leader

Designated meeting leader: Justin

### Requirements
- A list of features that are completed and ready to be included in the next release

### Summary
The designated meeting leader calls a meeting where all the features are viewed and presented. If a feature doesn't work as it is intended it is marked and recorded as non-completed.

If a non-completed feature can be made completed in a short period of time, another meeting is held which will determine if now everything is in place or additional time is needed.

### Artefacts
Input artefact: A list of features that are completed and ready to be included in the next release.

Output artefact: Document that acknowledges if all the features are working as intended or not.

# Release Phase
The Release Phase is a two week phase where the following procedures are taking place:
- Testing
- Documenting
- Planing and
- Releasing

## Testing procedures
### Local/Remote Feature Testing
#### Purpose
The purpose of this procedure is to test a new feature in order to be sure that all the required business logic is implemented and working correctly.

#### Scope
- Anyone

#### Requirements
- A Document explaining what the features does and how to test it.
- Feature available on the remote server

#### Summary
First a document needs to be available that explains what a feature does and how to test it. Without that document it would be impossible to make sure that everything is working correctly and as designed.

Once the document is read, testing can begin either using a local node or a remote node. The preference here is to do the testing on the remote node which in our case would be the Dev0 or Porcini server.

If all the required behaviour is implemented then this feature can be marked as tested on the global release excel sheet. It's necessary that at least two people test the feature in order to make sure that no oversight happens.

#### Artefacts
Input artefact: A Document explaining what the features does and how to test it.

Output artefact: Featured marked as tested on the global release excel sheet.

### Runtime (Storage) Upgrade Testing
#### Purpose
The purpose of this procedure is to make sure that a runtime upgrade will not cause issues when performed on Porcini or Root Network and that the storage migration code is handling the storage change correctly.

#### Scope
- Anyone

#### Requirements
- A Document explaining what storage has been moved and changed

#### Summary
A document with all the storage and runtime changes needs to be available.

After reading that document there are two activities that can be done:
1. Running the Runtime upgrade on Dev0 and monitoring it
2. Using try-runtime, storage-check and running the Runtime upgrade locally

Both activities SHOULD be done to decrease the chances of oversight.

#### Artefacts
Input artefact: A Document explaining what the features does and how to test it.

Output artefact: Runtime upgrade marked as tested on the global release excel sheet.

## Documenting procedures
### Documenting Feature
#### Purpose
The purpose of this procedure is to properly document a feature so all the stakeholders understand how it can be used.

#### Scope
- Anyone

#### Requirements
- A Document explaining what the features does and how to test it.

#### Summary
The amount of documentation that needs to be done depends on the feature. A large feature MUST be documented in the code, in ReadMe (if applicable) and in the User Documentation (if applicable).

All new extrinsics that are added need to have proper documentation and proper error and event names.
Existing extrinsics that have been changed need to have their documentation updated.

#### Artefacts
Input artefact: A Document explaining what the features does and how to test it.

Output artefact: Code documentation and/or ReadMe updated and/or User Documentation updated.

## Planing procedures
This procedures are the same one as the one mentioned in the `Planing Activities` section.

## Release procedures
### The Release Procedure
#### Purpose
The purpose of this procedure is to make sure that when a release happens that all the necessary and required artefacts are recorded and available.

#### Scope
- Release Coordinator

#### Requirements
- Global release excel sheet
- Document with a list of features that are ready for release

#### Summary
The Release Coordinator first makes sure that all features have been properly tested.

If everything is in green then the following needs to be done in the root repository:
- Update SPEC and pallet version.
- Update Client version if necessary.
- Remove old migration code.
- Tag created and run all tests against that tag
- Create Github Pre-Release or Release
- Generate Release artefacts (.wasm file)
- Populate the Release description with changes that have been done
- Publish Release

The last step now is to deploy the .wasm file and do the runtime upgrade on Porcini or Root

#### Artefacts
Input artefact: Global release excel sheet and Document with a list of features that are ready for release.

Output artefact: Published Github Pre-Release or Release with all necessary artefacts.

# Develop Phase
The Develop Phase is a two or three week phase where the procedures from `Development Activites` section are conducted.
Besides those procedures, there is one more that is available.

## Dev Chat
### Purpose
The purpose of this procedure is inform other team members on what each person is currently working on and on any news that might impact existing or future features.

### Scope
Mandatory personal involvement:
- The Root Network Dev Team

Designated meeting leader: Ken

Frequency: Two sessions per week, one session is half an hour long.

### Requirements
- No requirements

### Summary
Once the meetings starts a random member starts to talk about what they have done and what they will do. Once he is finished he appoints the next person who is to share his work that was done and that will be done. This goes on until all members have communicated their intentions.

### Artefacts
Input artefact: No input
Output artefact: No output

# What's next?
All the procedures in this document are purposely made concise and only contain the bare bone information. The reason for this is for us to first pick what procedure we want to have/implement and then expand the procedure with additional valuable information.

Some of the procedures are also keep vague because they are supposed to be supersede by work instruction which will be more details.

I am expecting that this document first will be analysed and checked for grammatical errors and after that it will be presented to all stakeholders to determine what procedures needs to be changes and what procedures can we accept and use in the next release cycle.

The internal deadline for this document to be completely done is end of February.