Ver código fonte

last after second review

Bedeho Mender 6 anos atrás
pai
commit
815caddf1e

+ 112 - 112
README.md

@@ -1,8 +1,8 @@
 <p align="center"><img width=200px src="landing-icon.png"></p>
-<p align="center"><img  src="landing-repo-headline.svg"></p>
+<p align="center"><img src="landing-repo-headline.png"></p>
 
 <div align="center">
-  <h4>Eventually, this all goes on-chain, read our :scroll: <a href="">whitepaper</a> :scroll:, we are on-chain governance maximalists!<h4>
+  <h4>Eventually, this all goes on-chain, read our :scroll: <a href="https://github.com/Joystream/whitepaper/blob/master/paper.pdf">whitepaper</a> :scroll:, we are on-chain governance maximalists!<h4>
 </div>
 <div align="center">
   <h5>The place to learn about Joystream project planning, collaboration and communication</h5>
@@ -15,31 +15,33 @@
 
 <div align="center">
   <h3>
-    <a href="#">
+    <a href="/testnets/athens">
       Athens Testnet
     </a>
     <span> | </span>
-    <a href="#">
+    <a href="/okrs">
       Live OKRs
     </a>
     <span> | </span>
-    <a href="#">
+    <a href="/meetings">
       Meetings
     </a>
     <span> | </span>
-    <a href="#">
+    <a href="https://github.com/Joystream/helpdesk/blob/master/README.md">
       Helpdesk
     </a>
-    <span> | </span>
-    <a href="#">
-      Contributing
-    </a>
   </h3>
 </div>
 
 # Table of contents
 
 - [Overview](#overview)
+- [Contribute](#contribute)
+- [Repository Index](#repository-index)
+- [Testnet Releases](#testnet-releases)
+    - [Live Testnet](#live-testnet)
+    - [Next Testnet](#next-testnet)
+    - [Past Testnets](#past-testnets)
 - [Project Management](#project-management)
     - [Why is this on Github?](#why-is-this-on-github?)
     - [Meetings](#meetings)
@@ -52,46 +54,64 @@
       - [Hierarchy](#hierarchy)
       - [Tracking](#tracking)
       - [Schema](#schema)
-    - [OKRs](#okrs)
-      - [Project OKRs](#project-okrs)
-      - [Quarterly OKRs](#quarterly-okrs)
-      - [Release OKRs](#release-okrs)
-      - [Personal OKRs](#personal-okrs)
-- [Testnet Releases](#testnet-releases)
-    - [Live Testnet](#live-testnet)
-    - [Next Testnet](#next-testnet)
-    - [Past Testnets](#past-testnets)
     - [Testnet Planning](#testnet-planning)
-      - [Set-by-step Process](#step-by-step-process)
       - [Branding](#branding)
       - [Testnet Directory](#testnet-directory)
       - [Roles](#roles)
         - [Release Manager](#release-manager)
         - [Specification Lead and Committee](#specification-lead-and-committee)
+      - [Set-by-step Process](#step-by-step-process)
+- [Github Policy](#github-policy)
 
 # Overview
 
 This landing repo as meant as a the best starting place to get a coherent view of how information is organised in this GitHub organization.
 
-# Repo Index
+# Contribute
+
+WIP.
+
+# Repository Index
 
 This is the set of key repos that
 
 | Repo                                                                                      | Description                                           | Maintainer      |
 | :-------------                                                                            | :-------------                                        | :-----------:   |
 | [substrate-runtime-joystream](https://github.com/Joystream/substrate-runtime-joystream)   | The Joystream substrate runtime.                      | @mnaamani       |
+| [substrate-node-joystream](https://github.com/Joystream/substrate-node-joystream)         | The Joystream substrate node.                         | @mnaamani       |
 | [apps](https://github.com/Joystream/apps)                                                 | The Pioneer application.                              | @siman          |
 | [storage-node-joystream](https://github.com/Joystream/storage-node-joystream)             | The storage node application.                         | @jfinkhaeuser   |
 | [whitepaper](https://github.com/Joystream/whitepaper)                                     | The Joystream whitepaper.                             | @bedeho         |
 | [communications](https://github.com/Joystream/communications)                             | The Joystream communications workspace and archive.   | @@bwhm          |
 
+# Testnet Releases
+
+<p align="center"><img width=200px src="testnet-logo.png"></p>
+
+Until the Joystream mainnet goes live, a sequence of test networks will be rolled out and deployed, and this section covers this activity.
+
+## Live Testnet
+
+Sparta
+
+## Next Testnet
+
+[Athens](/testnets/athens/README.md)
+
+## Past Testnets
+
+| Network         | Started           | Ended         | Release Plan    |
+| -------------   | -------------     | -----         | -----           |
+| Sparta          | x                 |   NA          |       NA        |
+| Mesopotamia     | x                 |   x           |       NA        |
+
 # Project Management
 
-<p align="center"><img src="project-management-headline.jpg"></p>
+<p align="center"><img width="400px" src="project-management-headline.jpg"></p>
 
 ## Why is this on Github?
 
-The reason this is placed in public view on Github is that two fold
+The reason this is placed in public view on Github is two fold
 
 - **Open Invitation:** Serve as an open invitation for anyone who wants to learn, comment and possibly contribute, to the current or future development of the Joystream project.
 
@@ -101,7 +121,7 @@ The reason this is placed in public view on Github is that two fold
 
 ### Itinerary
 
-Meeting itineraryies are prepared on a case by case basis, depending on the context, anda template for this, as well as an index of archived itineraries, can be found [here](/meetings).
+Meeting itineraries are prepared on a case by case basis, depending on the context, and a template for this, as well as an index of archived itineraries, can be found [here](/meetings).
 
 ### Meeting Types
 
@@ -147,7 +167,7 @@ A key result can be _assigned_ to a mix of people or other objectives. The _assi
 
 The OKRs can be classified into two separate families of types, first
 
-- **Project OKRs**: Project OKRs run over multiple years and are graded very rarely. They contain the root objectives that require no deeper justification. Every other objective must be justified directly, or indirectly through another key result, by virtue of its relevance to the project OKRs. The current set of such OKRs can be found [below](#project-okrs).
+- **Project OKRs**: Project OKRs can run over multiple years and are graded very rarely. They contain the root objectives that require no deeper justification. Every other objective must be justified directly, or indirectly through another key result, by virtue of its relevance to the project OKRs. The current set of such OKRs can be found [below](#project-okrs).
 
 - **Quarterly OKRs**: Every quarter, new OKRs for the given quarter are derived, referred to as quarterly OKRs. Only OKRs which have independent objectives are formally referred to as quarterly OKRs, any derivative OKR is not, even if derived at the start of a quarter. Importantly, they should contain very little detail about releases. The current set of such OKRs can be found [below](#quarterly-okrs).
 
@@ -157,9 +177,13 @@ and then second
 
 - **Group OKRs**: Group OKRs are defined by the set of stakeholders assigned to the key results, and in particular that there is more than one person involved. Typically this could be a set of people working as a team on some topic or problem. In principle, such an OKR can be rationalised by a mix of release and quarterly OKRs, but in practice it will most often just be one or the other. These OKRs should be flexible in time scope, and should be reorganized if circumstances change. The current set of such OKRs can be found [below](#group-okrs).
 
-- **Personal OKRs**: The exact same thing as personal OKRs, only applying to a single person only. The current set of such OKRs can be found [below](#personal-okrs).
+- **Personal OKRs**: The exact same thing as group OKRs, only applying to a single person only. The current set of such OKRs can be found [below](#personal-okrs).
+
+_Note:_ Any OKR from the first family is
+
+ - never a personal OKR, even if assigned to a single person
 
-_Note: As a matter of definition, its important to realise that any OKR from the first family, assigned to a single person, is not actually a personal OKR, or alternatively a group OKR if assigned to multiple people._
+ - never a group OKR, even if assigned to a multiple persons
 
 The following figure attempts to summarise how these OKR families and types are related, and their relevant temporal scopes.
 
@@ -193,7 +217,7 @@ The schema used for recording and tracking OKRs has the following form:
  - **Tracking Manager**: `<Name of person responsible for doing tracking, at given interval, and final grading>`
  - **Key Results**: `<If all key results have same assignment set, write here>`
    1. `<Statement of Key result>`
-     - `<Name of assignment>`: `<assignment weight>`
+     - `<Name of assignee>`: `<assignment weight>`
      - ...
  - **Tracking:**
 
@@ -201,89 +225,8 @@ The schema used for recording and tracking OKRs has the following form:
 |:--------:|:-----:|:-----:|:--------------:|
 | `<date&time>` | (`<... assignment set scores>`)  **Total KR score**  | ... |  **Tracked objective score** |
 
-# Testnet Releases
-
-<p align="center"><img width=200px src="testnet-logo.png"></p>
-
-..... say something general here ....
-
-## Live Testnet
-
-<p align="center">
-<img width="120px" src="testnets/athens/logo.png"/>
-</p>
-
-Sparta
-
-## Next Testnet
-
-<p align="center">
-<img width="120px" src="testnets/athens/logo.png"/>
-</p>
-
-[Athens](/testnets/athens/README.md)
-
-## Past Testnets
-
-| Network         | Started           | Ended         | Release Plan    |
-| -------------   | -------------     | -----         | -----           |
-| Sparta          | x                 |   NA          |       NA        |
-| Mesopotamia     | x                 |   x           |       NA        |
-
 ## Testnet Planning
 
-### Step-by-step Process
-
-This whole process should take no more than **X** days from start to finish, and involves the following sequence of events and corresponding deadlines.
-
-1. The following must be determined no later than **the day before the prior testnet release.**
-
-    - [**RM**](#release-manager)
-    - testnet name, denoted by `TESTNET_NAME`
-    - tentative release date
-
-2. **RM** shall have done the following no later than at **the day after the prior testnet release.**
-
-    - created PR establishing a new [testnet directory](testnet-directory), where
-        - the release name is set to `TESTNET_NAME`
-        - the naming rationale is left blank, unless it is ready
-        - the goal is left blank, unless it is ready
-        - the logomark is left blank, unless it is ready
-
-    - initiated creation of possibly missing logomark
-
-    - scheduled a meeting time for the [launch meeting](launch-meeting) no later than the next available working day when all core contributors are available.
-
-    - create a subdirectory of the [meeting](meetings) directory that has itinerary with appropriate agenda
-
-3. Conduct launch meeting.
-
-4. After the meeting is over, the **RM** shall on the same day have the testnet directory pull request merged with completed itinerary.
-
-5. Leads must complete their user stories contributions, in the form of PRs into the meeting directory, before the user stories meeting starts.
-
-6. Conduct user stories meeting.
-
-7. After the meeting is over, the **RM** shall have the lead pull requests merged, with possible modifications, no later than **the day after**.
-
-8. Leads must complete their release plan sections, in the form of PRs into the meeting directory, before the release plan finalisation meeting starts.
-
-9. Conduct release plan finalisation meeting.
-
-10. After the meeting is over, the **RM** shall on the same days
-
-    - create a github project per release objective on the [Joystream Github Organisation](https://github.com/orgs/Joystream/projects) which kanban boards with standardized columns: `TODO`, `In progress`, `Done` and `Halted`.
-
-    - update release document link to relevant github projects.
-
-    - updates the label set to reflect any new possible products
-
-10. Specification work begins, and is scheduled and organised on an ad-hoc basis. Anyone unaffected by this work can continue to move forward immediately.
-
-11. Leads must convert their release plan contributions into tangible tasks, in the form of github issues on the relevant github project created. After this process, the release plan itself should no longer be consulted, also if changes are made.
-
-12. Release planning meetings are conducted on a per-need basis, typically more frequently as the release date approaches.
-
 ### Branding
 
 All releases have the following branding materials, which should be summarised in a markdown _Branding Document_
@@ -311,7 +254,7 @@ Each release is directed by a _Release Manager_ (**RM**) who is responsible for
 
  - Moving the release process forward and on track.
  - Calling and conducting release meetings.
- - Preparing all adminstrative pull requests for the release on this repo.
+ - Preparing all administrative pull requests for the release on this repo.
 
 #### Leads
 
@@ -359,6 +302,63 @@ If feasible, then proceed with
 
 Open ended technical meetings which are conducted iteratively with implementing out parts of the release.
 
-# Helpdesk
+### Step-by-step Process
 
-WIP.
+This whole process should take no more than **X** days from start to finish, and involves the following sequence of events and corresponding deadlines.
+
+1. The following must be determined no later than **the day before the prior testnet release.**
+
+    - [**RM**](#release-manager)
+    - testnet name, denoted by `TESTNET_NAME`
+    - tentative release date
+
+2. **RM** shall have done the following no later than at **the day after the prior testnet release.**
+
+    - created PR establishing a new [testnet directory](testnet-directory), where
+        - the release name is set to `TESTNET_NAME`
+        - the naming rationale is left blank, unless it is ready
+        - the goal is left blank, unless it is ready
+        - the logomark is left blank, unless it is ready
+
+    - initiated creation of possibly missing logomark
+
+    - scheduled a meeting time for the [launch meeting](launch-meeting) no later than the next available working day when all core contributors are available.
+
+    - create a subdirectory of the [meeting](meetings) directory that has itinerary with appropriate agenda
+
+3. Conduct launch meeting.
+
+4. After the meeting is over, the **RM** shall on the same day have the testnet directory pull request merged with completed itinerary.
+
+5. Leads must complete their user stories contributions, in the form of PRs into the meeting directory, before the user stories meeting starts.
+
+6. Conduct user stories meeting.
+
+7. After the meeting is over, the **RM** shall have the lead pull requests merged, with possible modifications, no later than **the day after**.
+
+8. Leads must complete their release plan sections, in the form of PRs into the meeting directory, before the release plan finalisation meeting starts.
+
+9. Conduct release plan finalisation meeting.
+
+10. After the meeting is over, the **RM** shall on the same days
+
+    - create a github project per release objective on the [Joystream Github Organisation](https://github.com/orgs/Joystream/projects) which kanban boards with standardized columns: `TODO`, `In progress`, `Done` and `Halted`.
+
+    - update release document link to relevant github projects.
+
+    - updates the label set to reflect any new possible products
+
+10. Specification work begins, and is scheduled and organised on an ad-hoc basis. Anyone unaffected by this work can continue to move forward immediately.
+
+11. Leads must convert their release plan contributions into tangible tasks, in the form of github issues on the relevant github project created. After this process, the release plan itself should no longer be consulted, also if changes are made.
+
+12. Release planning meetings are conducted on a per-need basis, typically more frequently as the release date approaches.
+
+# Github Policy
+
+WIP: describe how we use github, in particular
+
+- repo creation, naming and formatting policies
+- how to use this repo, in particular managing label sets, projects, etc.
+- explain gitflow
+- collaboration, membership status policies.

BIN
figure-source.sketch


BIN
landing-repo-headline.png


+ 0 - 11
landing-repo-headline.svg

@@ -1,11 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<svg width="552px" height="91px" viewBox="0 0 552 91" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
-    <!-- Generator: Sketch 53.2 (72643) - https://sketchapp.com -->
-    <title>Landing Repo</title>
-    <desc>Created with Sketch.</desc>
-    <g id="Headlines" stroke="none" stroke-width="1" fill="none" fill-rule="evenodd" font-family="HelveticaNeue-UltraLight, Helvetica Neue" font-size="100" font-weight="200">
-        <text id="Landing-Repo" fill="#000000">
-            <tspan x="-4.65" y="72">Landing Repo</tspan>
-        </text>
-    </g>
-</svg>

+ 9 - 4
meetings/README.md

@@ -1,5 +1,11 @@
-<p align="center"><img width=300px src="okr-logo.png"></p>
-<p align="center" style="font-size:100px;font-weight:100;">Meetings</p>
+<p align="center"><img src="meetings-headline.png"></p>
+
+<div align="center">
+  <h4>Take a look at what we :loudspeaker: talk :loudspeaker: about, our :pencil: meeting notes :pencil:, and join if you want! </h4>
+</div>
+<div align="center">
+  <h5>The line between bureaucracy and rigour is 1px thin, but what are we to do? :pray:</h5>
+</div>
 
 # Table of contents
 
@@ -19,7 +25,6 @@ This is the index of past meetings with itineraries, they should all be stored i
 | :-------------  | :-------------   |:-------------:            | :-----:                                                                                         | :-----:   |
 | x               | x                | x                         | x                                                                                               | x         |
 
-
 # Itinerary Template
 
 - **Nr:** `meeting identifier`
@@ -30,7 +35,7 @@ This is the index of past meetings with itineraries, they should all be stored i
 - **Lead**: `person is responsible for time keeping, note taking and post-meeting`
 - **Participants**: `persons known to be participating in advance`
   - `Name of person`
-  - `...``
+  - `...`
 - **Agenda:**
 
 | Time Required         | Item            | Decision  |

BIN
meetings/meetings-headline.png


+ 47 - 41
okrs/README.md

@@ -1,21 +1,27 @@
-<p align="center"><img width=300px src="okr-logo.png"></p>
-<p align="center" style="font-size:100px;font-weight:100;">Joystream Project Objectives and Key Results</p>
+<p align="center"><img src="live-okrs-headline.png"></p>
+
+<div align="center">
+  <h4>These are our currently :microphone: live objectives :microphone: and tracked achievement :crown: </h4>
+</div>
+<div align="center">
+  <h5>The line between bureaucracy and rigour is 1px thin, but what are we to do? :pray:</h5>
+</div>
 
 # Table of contents
 
-- [OKRs](#okrs)
-  - [Project OKRs](#project-okrs)
-  - [Quarterly OKRs](#quarterly-okrs)
-  - [Release OKRs](#release-okrs)
-  - [Personal OKRs](#personal-okrs)
+- [Archive](#archive)
+- [Project OKRs](#project-okrs)
+- [Quarterly OKRs](#quarterly-okrs)
+- [Release OKRs](#release-okrs)
+- [Personal OKRs](#personal-okrs)
 
-# OKRs
+# Archive
 
-Archived OKRs are found in [archive](okr), below only live OKRs are found.
+Archived OKRs are found in [archive](/archive), below only live OKRs are found.
 
-## Project OKRs
+# Project OKRs
 
-### Objective: `Launch a functional, upgradable video platform, governed and operated by a vibrant community`
+## !WIP! :construction_worker: Objective: `Launch a functional, upgradable video platform, governed and operated by a vibrant community`
 - **KR Measurement Deadline:** Joystream autonomous network live
 - **Tracked:** Every 6 months
 - **Tracking Manager:** Martin
@@ -24,35 +30,36 @@ Archived OKRs are found in [archive](okr), below only live OKRs are found.
   2. `There are at least 10 builders, with at least 2 in a full time capacity`
   3. `There are at least 100 active governance or operations focused daily active members`
   4. `There are at least 10000 daily active members, as measured by any kind of use of the platform`
-  5. `<... something about publishers/content. ..>`
+  5. `There are at least 200 active publishers, where active is defined as publishing at least once per month`
 - **Tracking:**
 
 | Date     | KR #1 | KR #2 | KR #3 | KR #4 | KR #5 |  Total |
 |:--------:|:-----:|:-----:|:-----:|:-----:|:-----:|:------:|
 | 01.06.19 |    NA  |   NA    |  NA     |  NA     |    NA    |     **NA**  |
 
-## Quarterly OKRs
+# Quarterly OKRs
 
-### Objective: `Expand the Jsgenesis team`
-- **KR Measurement Deadline:** xxxx
+## Objective: `Expand the Jsgenesis team`
+- **KR Measurement Deadline:** End of Q1
 - **Tracked:** Weekly
 - **Tracking Manager:** Martin
-- **Key Results:** all assigned to Martin and Bedeho equally
-  1. `Add full 3 full time blockchain developers`
-  3. `Add full 1 time full stack developer`
+- **Key Results:** Martin and Bedeho equally
+  1. `Add 3 full time blockchain developers`
+  2. `Add 1 full time UI/UX designer/team`
+  3. `Add full 1 full stack developer`
   4. `Source 25 candidates outside of angel/jsg/dribble/hh`
   5. `Interview at least 25 candidates once, and 15 candidates twice`
 - **Tracking:**
 
 | Date     | KR #1 | KR #2 | KR #3 | KR #4 | KR #5 |  Total |
 |:--------:|:-----:|:-----:|:-----:|:-----:|:-----:|:------:|
-| 18.03.19 |     x  |   x    |  x     |  x     |    x    |     **x**  |
+| 26.03.19 | 0.33  |   1    |  1   |  0.36 |  0.3  | **x**  |
 
-### Objective: `Launch and grow Staked podcast`
+## Objective: `Launch and grow Staked podcast`
 - **KR Measurement Deadline:** End of Q1
 - **Tracked:** Every 2 weeks
 - **Tracking Manager:** Martin
-- **Key Results:**
+- **Key Results:** Martin and Bedeho equally
   1. `Launch a new branded podcast available in all major podcast channels`
   2. `Record and publish 5 first episodes`
   3. `Get 100 subscribers`
@@ -61,12 +68,12 @@ Archived OKRs are found in [archive](okr), below only live OKRs are found.
 
 | Date     | KR #1 | KR #2 | KR #3 | KR #4 |  Total |
 |:--------:|:-----:|:-----:|:-----:|:-----:|:------:|
-| 18.03.19      |   1    |   0.4    |   x   |  x      |  **x**     |
+| 18.03.19 |   1    |   0.4    |   x   |  x      |  **x**     |
 
-## Release OKRs
+# Release OKRs
 
-### Objective: `Launch Athens network`
-- **KR Measurement Deadline**: x time after Athens launch
+## Objective: `Launch Athens network`
+- **KR Measurement Deadline**: 1 week after Athens launch
 - **Tracked**: Every monday
 - **Tracking Manager**: Martin
 - **Key Results**:
@@ -77,13 +84,13 @@ Archived OKRs are found in [archive](okr), below only live OKRs are found.
     - Jens: 0.5
     - Martin+Bedeho: 0.5
   3. `Have second council upgrade consensus after reaching quorum`
-    - Alex: 0.3
-    - Mokhtar: 0.3
-    - Martin: 0.3
+    - Alex: 1/3
+    - Mokhtar: 1/3
+    - Martin: 1/3
   4. `20 Uploads (100min) and 100 Downloads not including Jsgenesis`
-    - Jens: 0.3
-    - Alex: 0.3
-    - Mokhtar: 0.3
+    - Jens: 1/3
+    - Alex: 1/3
+    - Mokhtar: 1/3
   5. `75 Memberships created (not including Jsgenesis) at a min 1/2 membership/unique view ratio`
     - Mokhtar: 0.5
     - Alex: 0.5
@@ -93,32 +100,31 @@ Archived OKRs are found in [archive](okr), below only live OKRs are found.
 |:--------:|:-----:|:-----:|:-----:|:-----:|:-----:|:--------------:|
 | 18.03.19 | (1.0 , 0.75)  **0.873**  | (0.66 , 0.9) **0.78**  | (1.0 , 0.8 , 0.8) **0.933**  |  (0.66 , 0, 0) **0.33** |  (0.8 , 0.65) **0.725** |  **0,7282** |
 
-
-## Group OKRs
+# Group OKRs
 
 Fill in if needed.
 
-## Personal OKRs
+# Personal OKRs
 
-### `Alex` (@siman)
+## `Alex` (@siman)
 
 Fill in if needed.
 
-### `Mokhtar` (@mnaamani)
+## `Mokhtar` (@mnaamani)
 
 Fill in if needed.
 
-### `Martin` (@bwhm)
+## `Martin` (@bwhm)
 
 Fill in if needed.
 
-### `Jens` (@jfinkhaeuser)
+## `Jens` (@jfinkhaeuser)
 
 Fill in if needed.
 
-### `Bedeho` (@bedeho)
+## `Bedeho` (@bedeho)
 
-#### Objective: `Make Joystream easier to understand for prospective community members and Jsgenesis hires`
+### Objective: `Make Joystream easier to understand for prospective community members and Jsgenesis hires`
 - **KR Measurement Deadline**: xxxx
 - **Tracked**: Weekly
 - **Key Results**:
@@ -130,7 +136,7 @@ Fill in if needed.
 |:--------:|:-----:|:-----:|:------:|
 | 18.03.19 |   0.98  | 0.7  | **0.85**   |
 
-#### Objective: `Establish critical routines for future productivity`
+### Objective: `Establish critical routines for future productivity`
 - **KR Measurement Deadline**: xxxx
 - **Tracked**: Weekly
 - **Key Results**:

BIN
okrs/live-okrs-headline.png


BIN
project-management/.DS_Store


+ 0 - 264
project-management/README.md

@@ -1,264 +0,0 @@
-<p align="center"><img width=300px src="okr-logo.png"></p>
-<p align="center" style="font-size:100px;font-weight:100;">Project Management</p>
-
-# Table of contents
-
-- [Why is this on Github?](#why-is-this-on-github?)
-- [Meetings](#meetings)
-  - [Daily standup](#daily-standup)
-  - [Monday all-hands](#monday-all-hands)
-  - [Release meeting](#release-meeting)
-- [OKR System](#okr-system)
-  - [Assignment](#assignment)
-  - [OKR types](#okr-types)
-  - [Hierarchy](#hierarchy)
-  - [Tracking](#tracking)
-  - [Schema](#schema)
-- [OKRs](#okrs)
-  - [Project OKRs](#project-okrs)
-  - [Quarterly OKRs](#quarterly-okrs)
-  - [Release OKRs](#release-okrs)
-  - [Personal OKRs](#personal-okrs)
-
-# Why is this on Github?
-
-The reason this is placed in public view on Github is that two fold
-
-- **Open Invitation:** Serve as an open invitation for anyone who wants to learn, comment and possibly contribute, to the current or future development of the Joystream project.
-
-- **Best Practices**: Establish best practices which can be replicated by the platform, when it is fully live, in how to collaboratively build and manage the platform using open tools. In particular, the current plan is that the platform has a built in Github equivalent, which thus would allow the use of these conventions.
-
-# Meetings
-
-## Itinerary
-
-Meeting itineraryies are prepared on a case by case basis, depending on the context, anda template for this, as well as an index of archived itineraries, can be found [here](/meetings).
-
-## Meeting Types
-
-### Daily standup
-
-- **Description:** Everyone states, within 1 minute, what they accomplished the prior day, and what the goals are for the day. After this, people can start separate calls which need not be conducted in plenum.
-- **When:** Every day at 10am (GMT)
-- **Where:** Zoom
-- **Participant:** Core Jsgenesis team _must_ be present, any one else is welcome (join Rocket.Chat for invite).
-- **Record&Publish:** YES, if no participant objects.
-
-### Monday all-hands
-
-- **Description:** Everyone states individual:
-  1. **OKR Tracking**: Track your OKRs and OKR assignments
-  2. **Health Comments:** Any points you wish to discuss related to things like team health, code health, workflow/system health etc.
-  3. **Weekly Priorities:** Your top 3-5 priorities this week. *Not* the same as your tasks today.
-  4. **Announcements:** Anything you think should be brought to everyones attention.
-- **When:** Every working monday at 10am (GMT)
-- **Where:** Zoom
-- **Participant:** Core Jsgenesis team _must_ be present, any one else is welcome (join Rocket.Chat for invite).
-- **Record&Publish:** YES, if no participant objects.
-
-### Release meeting
-
-- **Description:** Discussion about impending testnet release.
-- **When:** Weekly
-- **Where:** Zoom
-- **Participant:** Core release team _must_ be present, any one else is welcome (join Rocket.Chat for invite).
-- **Record&Publish:** YES, if no participant objects.
-
-# OKR system
-
-Project management is primarily centred around planning and tracking OKRs. OKRs is a planning and project management system, which can be reviewed in further detail [here](https://en.wikipedia.org/wiki/OKR).
-
-## Assignment
-
-A key result can be _assigned_ to a mix of people or other objectives. The _assignment set_ of a key result consitutes the set of relevant actors, directly or indirectly - for OKRs, that are working to satisfy the result. Each assignment is given a weight from 0 to 1, and the total weight across an assignment set is 1. Some key results, in particular for very higher order OKRs, may not have assignments at all times.
-
-## OKR types
-
-The OKRs can be classified into two separate families of types, first
-
-- **Project OKRs**: Project OKRs run over multiple years and are graded very rarely. They contain the root objectives that require no deeper justification. Every other objective must be justified directly, or indirectly through another key result, by virtue of its relevance to the project OKRs. The current set of such OKRs can be found [below](#project-okrs).
-
-- **Quarterly OKRs**: Every quarter, new OKRs for the given quarter are derived, referred to as quarterly OKRs. Only OKRs which have independent objectives are formally referred to as quarterly OKRs, any derivative OKR is not, even if derived at the start of a quarter. Importantly, they should contain very little detail about releases. The current set of such OKRs can be found [below](#quarterly-okrs).
-
-- **Release OKRs**: Releases are planned one after the other on a rolling basis, and the release OKRs correspond to a single release. Only OKRs which have independent objectives are formally referred to as release OKRs, any derivative OKR is not, even if derived at in the context of a release. The current set of such OKRs can be found [below](#release-okrs)
-
-and then second
-
-- **Group OKRs**: Group OKRs are defined by the set of stakeholders assigned to the key results, and in particular that there is more than one person involved. Typically this could be a set of people working as a team on some topic or problem. In principle, such an OKR can be rationalised by a mix of release and quarterly OKRs, but in practice it will most often just be one or the other. These OKRs should be flexible in time scope, and should be reorganized if circumstances change. The current set of such OKRs can be found [below](#group-okrs).
-
-- **Personal OKRs**: The exact same thing as personal OKRs, only applying to a single person only. The current set of such OKRs can be found [below](#personal-okrs).
-
-_Note: As a matter of definition, its important to realise that any OKR from the first family, assigned to a single person, is not actually a personal OKR, or alternatively a group OKR if assigned to multiple people._
-
-The following figure attempts to summarise how these OKR families and types are related, and their relevant temporal scopes.
-
-![alt text](OKR-figure.svg "OKR Tree")
-
-## Hierarchy
-
-All OKRs, except the project OKR, should be derived, in terms of its objective, from one or more key results of already existing higher order OKRs.
-
-## Tracking
-
-In order to keep track of whether a key result, and thus the corresponding objective, will in the end be satisfied, forecasts are tracked throughout the lifetime of an OKR. Each OKR has its own periodic tracking of progress, and to compute the its forecasted value, do as indicated in the example figure below.
-
-![alt text](KR-Weighting.svg "Key Result ")
-
-Briefly, do a topological sort of the key result graph, where having an objective in the result assignment set counts towards the indegree. Then just do ascending weighted averaging of scores, where key results are simply averaged into objective scores. Importantly, in order to do this, one has to get personal scores on key results, and there are two modes of doing this
-
-- **Naive**: Simply evaluate the key result statement directly based on available data at the time. For example, if the result is `Get $100 in revenue`, and one has $20 so far, then the score would be 0.2. This method is often suitable, but no if partial work is unlikely to have had any real world effects while tracking.
-
-- **Planned Work Done**: Fraction of estimated total hours required that have been completed. This means that, if the estimate of total time required changes, then the score can change, even there is not change in actual hours completed.
-
-The mode used depend on the nature of the key result.
-
-## Schema
-
-The schema used for recording and tracking OKRs has the following form:
-
- - **Objective:** `<Name of objective>`
- - **KR Measurement Deadline**: `<When the final grading is conducted>`
- - **Tracked**: `<Time interval at which OKR is tracked>`
- - **Tracking Manager**: `<Name of person responsible for doing tracking, at given interval, and final grading>`
- - **Key Results**: `<If all key results have same assignment set, write here>`
-   1. `<Statement of Key result>`
-     - `<Name of assignment>`: `<assignment weight>`
-     - ...
- - **Tracking:**
-
-| Date     | KR #1 | ... |  Total |
-|:--------:|:-----:|:-----:|:--------------:|
-| `<date&time>` | (`<... assignment set scores>`)  **Total KR score**  | ... |  **Tracked objective score** |
-
-# OKRs
-
-## Project OKRs
-
-### Objective: `Launch a functional, upgradable video platform, governed and operated by a vibrant community`
-- **KR Measurement Deadline:** Joystream autonomous network live
-- **Tracked:** Every 6 months
-- **Tracking Manager:** Martin
-- **Key Results:**
-  1. `All (IT) infrastructure roles are contested, and at least one professional for profit operation is taking part`
-  2. `There are at least 10 builders, with at least 2 in a full time capacity`
-  3. `There are at least 100 active governance or operations focused daily active members`
-  4. `There are at least 10000 daily active members, as measured by any kind of use of the platform`
-  5. `<... something about publishers/content. ..>`
-- **Tracking:**
-
-| Date     | KR #1 | KR #2 | KR #3 | KR #4 | KR #5 |  Total |
-|:--------:|:-----:|:-----:|:-----:|:-----:|:-----:|:------:|
-| 01.06.19 |    NA  |   NA    |  NA     |  NA     |    NA    |     **NA**  |
-
-## Quarterly OKRs
-
-### Objective: `Expand the Jsgenesis team`
-- **KR Measurement Deadline:** xxxx
-- **Tracked:** Weekly
-- **Tracking Manager:** Martin
-- **Key Results:** all assigned to Martin and Bedeho equally
-  1. `Add full 3 full time blockchain developers`
-  3. `Add full 1 time full stack developer`
-  4. `Source 25 candidates outside of angel/jsg/dribble/hh`
-  5. `Interview at least 25 candidates once, and 15 candidates twice`
-- **Tracking:**
-
-| Date     | KR #1 | KR #2 | KR #3 | KR #4 | KR #5 |  Total |
-|:--------:|:-----:|:-----:|:-----:|:-----:|:-----:|:------:|
-| 18.03.19 |     x  |   x    |  x     |  x     |    x    |     **x**  |
-
-### Objective: `Launch and grow Staked podcast`
-- **KR Measurement Deadline:** End of Q1
-- **Tracked:** Every 2 weeks
-- **Tracking Manager:** Martin
-- **Key Results:**
-  1. `Launch a new branded podcast available in all major podcast channels`
-  2. `Record and publish 5 first episodes`
-  3. `Get 100 subscribers`
-  4. `Get 500 listens`
-- **Tracking:**
-
-| Date     | KR #1 | KR #2 | KR #3 | KR #4 |  Total |
-|:--------:|:-----:|:-----:|:-----:|:-----:|:------:|
-| 18.03.19      |   1    |   0.4    |   x   |  x      |  **x**     |
-
-## Release OKRs
-
-### Objective: `Launch Athens network`
-- **KR Measurement Deadline**: x time after Athens launch
-- **Tracked**: Every monday
-- **Tracking Manager**: Martin
-- **Key Results**:
-  1. `Get 10 claims per $ for tokens on our faucet`
-    - Mokhtar: 0.5
-    - Martin: 0.5
-  2. `Have all episodes of the Staked (4) and Make_World (n) podcast in the content directory`
-    - Jens: 0.5
-    - Martin+Bedeho: 0.5
-  3. `Have second council upgrade consensus after reaching quorum`
-    - Alex: 0.3
-    - Mokhtar: 0.3
-    - Martin: 0.3
-  4. `20 Uploads (100min) and 100 Downloads not including Jsgenesis`
-    - Jens: 0.3
-    - Alex: 0.3
-    - Mokhtar: 0.3
-  5. `75 Memberships created (not including Jsgenesis) at a min 1/2 membership/unique view ratio`
-    - Mokhtar: 0.5
-    - Alex: 0.5
-- **Tracking:**
-
-| Date     | KR #1 | KR #2 | KR #3 | KR #4 | KR #5 |  Total |
-|:--------:|:-----:|:-----:|:-----:|:-----:|:-----:|:--------------:|
-| 18.03.19 | (1.0 , 0.75)  **0.873**  | (0.66 , 0.9) **0.78**  | (1.0 , 0.8 , 0.8) **0.933**  |  (0.66 , 0, 0) **0.33** |  (0.8 , 0.65) **0.725** |  **0,7282** |
-
-
-## Group OKRs
-
-Fill in if needed.
-
-## Personal OKRs
-
-### `Alex` (@siman)
-
-Fill in if needed.
-
-### `Mokhtar` (@mnaamani)
-
-Fill in if needed.
-
-### `Martin` (@bwhm)
-
-Fill in if needed.
-
-### `Jens` (@jfinkhaeuser)
-
-Fill in if needed.
-
-### `Bedeho` (@bedeho)
-
-#### Objective: `Make Joystream easier to understand for prospective community members and Jsgenesis hires`
-- **KR Measurement Deadline**: xxxx
-- **Tracked**: Weekly
-- **Key Results**:
-  1. `Publish first whitepaper draft`
-  2. `Add role list to joystream.org`
-- **Tracking:**
-
-| Date     | KR #1 | KR #2 |  Total |
-|:--------:|:-----:|:-----:|:------:|
-| 18.03.19 |   0.98  | 0.7  | **0.85**   |
-
-#### Objective: `Establish critical routines for future productivity`
-- **KR Measurement Deadline**: xxxx
-- **Tracked**: Weekly
-- **Key Results**:
-  1. `Draft planning framework for releases, quarters and longer term`
-  2. `Come up with specification framework`
-  3. `Learn Rust and Substrate`
-  4. `Draft framework for how to plan on Github`
-- **Tracking:**
-
-| Date     | KR #1 | KR #2 | KR #3 | KR #4 |  Total |
-|:--------:|:-----:|:-----:|:-----:|:-----:|:-----:|
-| 18.03.19 |  0.6 |  0.1 | 0.1  | 0  | **0**  |

+ 0 - 159
testnets/README.md

@@ -1,159 +0,0 @@
-<p align="center"><img width=200px src="testnet-logo.png"></p>
-<p align="center" style="font-size:100px;font-weight:100;">Testnet Releases</p>
-
-# Table of contents
-
-- [Live Testnet](#live-testnet)
-- [Next Testnet](#next-testnet)
-- [Past Testnets](#past-testnets)
-- [Testnet Planning](#testnet-planning)
-  - [Set-by-step Process](#step-by-step-process)
-  - [Branding](#branding)
-  - [Testnet Directory](#testnet-directory)
-  - [Roles](#roles)
-    - [Release Manager](#release-manager)
-    - [Specification Lead and Committee](#specification-lead-and-committee)
-
-# Live Testnet
-
-Sparta <=== add image
-
-# Next Testnet
-
-[Athens](athens/README.md) <=== add image
-
-# Past Testnets
-
-| Network         | Started           | Ended         | Release Plan    |
-| -------------   | -------------     | -----         | -----           |
-| Sparta          | x                 |   NA          |       NA        |
-| Mesopotamia     | x                 |   x           |       NA        |
-
-# Testnet Planning
-
-## Step-by-step Process
-
-This whole process should take no more than **X** days from start to finish, and involves the following sequence of events and corresponding deadlines.
-
-1. The following must be determined no later than **the day before the prior testnet release.**
-
-    - [**RM**](#release-manager)
-    - testnet name, denoted by `TESTNET_NAME`
-    - tentative release date
-
-2. **RM** shall have done the following no later than at **the day after the prior testnet release.**
-
-    - created PR establishing a new [testnet directory](testnet-directory), where
-        - the release name is set to `TESTNET_NAME`
-        - the naming rationale is left blank, unless it is ready
-        - the goal is left blank, unless it is ready
-        - the logomark is left blank, unless it is ready
-
-    - initiated creation of possibly missing logomark
-
-    - scheduled a meeting time for the [launch meeting](launch-meeting) no later than the next available working day when all core contributors are available.
-
-    - create a subdirectory of the [meeting](meetings) directory that has itinerary with appropriate agenda
-
-3. Conduct launch meeting.
-
-4. After the meeting is over, the **RM** shall on the same day have the testnet directory pull request merged with completed itinerary.
-
-5. Leads must complete their user stories contributions, in the form of PRs into the meeting directory, before the user stories meeting starts.
-
-6. Conduct user stories meeting.
-
-7. After the meeting is over, the **RM** shall have the lead pull requests merged, with possible modifications, no later than **the day after**.
-
-8. Leads must complete their release plan sections, in the form of PRs into the meeting directory, before the release plan finalisation meeting starts.
-
-9. Conduct release plan finalisation meeting.
-
-10. After the meeting is over, the **RM** shall on the same days
-
-    - create a github project per release objective on the [Joystream Github Organisation](https://github.com/orgs/Joystream/projects) which kanban boards with standardized columns: `TODO`, `In progress`, `Done` and `Halted`.
-
-    - update release document link to relevant github projects.
-
-    - updates the label set to reflect any new possible products
-
-10. Specification work begins, and is scheduled and organised on an ad-hoc basis. Anyone unaffected by this work can continue to move forward immediately.
-
-11. Leads must convert their release plan contributions into tangible tasks, in the form of github issues on the relevant github project created. After this process, the release plan itself should no longer be consulted, also if changes are made.
-
-12. Release planning meetings are conducted on a per-need basis, typically more frequently as the release date approaches.
-
-## Branding
-
-All releases have the following branding materials, which should be summarised in a markdown _Branding Document_
-
-- **Name:** Our current naming system is important historical ancient cities in the development of new political systems. It's still not clear if we will just stick to ancient cities, or move forward in time also (TBD).
-- **Naming Rationale:** A brief 40-150 word text about the significance of this city in our context.
-- **Goal:** A brief 100-200 word text about what technical and community goals we are trying to achieve.
-- **Logomark:** Illustrated logomark corresponding to name.
-
-## Testnet Directory
-
-All releases should have a corresponding _release directory_ in the `/testnets` directory of this repo, and it should have the following structure
-
-- `RELEASE_NAME`
-  - `README.md`: Release document.
-  - **WIP**`specification.md`: Testnet speficiation.
-  - `/branding`: A directory which includes a branding document and related assets, as described in the branding [section](branding)
-  - `/tutorials`: User facing tutorials for participating on the network.
-
-## Roles
-
-### Release Manager
-
-Each release is directed by a _Release Manager_ (**RM**) who is responsible for
-
- - Moving the release process forward and on track.
- - Calling and conducting release meetings.
- - Preparing all adminstrative pull requests for the release on this repo.
-
-### Leads
-
-A [release plan](release-plan-template.md) will consist of a set of projects, each with a corresponding lead, these are referred to as the _leads_.
-
-### Specification Lead and Committee
-
-The specification lead is responsible for moving the specification process forward, and the committee is anyone who is expected to contribute.
-
-**WIP: we need to connect this to broader information about our specification work, but that is not done yet**
-
-## Standard Release Meetings
-
-### Launch Meeting
-
-First release meeting, should take no more than **45 minutes**, with agenda
-
-1. Propose set of release OKRs based on review of
-    - open help desk issues that have bearing on release  
-    - any possibly finalised OKRs from prior release
-    - project OKRs
-2. Identify set of projects, products etc. and assign leads.
-3. Assign responsibility to someone for finalising outstanding branding assets, which must be delivered no later than **five days after this meeting**
-4. Schedule the [user stories meeting](#user-stories-meeting) to no later than **two working days after this meeting**.
-
-### User Stories Meeting
-
-Second release meeting, should take no more than **90 minutes**, with agenda
-
-1. For experiences identified in the [launch meeting](launch-meeting), review proposed user stories suggestions prepared by each lead, and settle on final set of stories
-2. Schedule the [Release Plan Finalisation Meeting](#release-plan-finalisation-meeting) to no later than **two working days after this meeting**.
-
-### Release Plan Finalisation Meeting
-
-Third release meeting, should take no more than **90 minutes**, with agenda
-
-1. Finalise release plan based on lead proposals
-2. Evaluate whether plan is feasible based on projected total load on contributors, and tentative release date. If not feasible, try to make minor modifications of scope or deadline. If that also does not work, go back and redo process from launch meeting step.
-
-If feasible, then proceed with
-
-3. If a specification is to be done, assign a [specification lead and committee](Specification Lead and Committee), and schedule first [specification planning meeting](#specification-planning-meeting)
-
-### Specification Planning meeting
-
-Open ended technical meetings which are conducted iteratively with implementing out parts of the release.

+ 86 - 102
testnets/athens/README.md

@@ -1,23 +1,11 @@
 <p align="center"><img width=200px src="logo.png"></p>
-<p align="center"><img src="athens-testnet-headline.svg"></p>
+<p align="center"><img src="athens-testnet-headline.png"></p>
 
 <div align="center">
   <h3>
-    <a href="https://choo.io">
+    <a href="#">
       Specification
     </a>
-    <span> | </span>
-    <a href="https://github.com/choojs/choo-handbook">
-      OKRs
-    </a>
-    <span> | </span>
-    <a href="https://github.com/YerkoPalma/awesome-choo">
-      Products
-    </a>
-    <span> | </span>
-    <a href="https://github.com/YerkoPalma/awesome-choo">
-      Milestones
-    </a>
   </h3>
 </div>
 
@@ -85,8 +73,6 @@ NA.
 
 # Release Plan
 
-Read more about how a release plan is used, and how it is generated, [here](....).
-
 ## Manager
 
 `Martin`
@@ -114,9 +100,9 @@ Read more about how a release plan is used, and how it is generated, [here](....
 
 ## Risks
 
-- <span style="color:blue">Jens</span> may not be able to reliably participate, and its not clear when new TT dev will be found and onboarded.
+- **Jens** may not be able to reliably participate, and its not clear when new TT dev will be found and onboarded.
 
-- <span style="color:blue">Bedeho</span> will try to contribute on Runtime work, but he also has to get familiar with Rust & Substrate, as well as other unreliable priorities.
+- **Bedeho** will try to contribute on Runtime work, but he also has to get familiar with Rust & Substrate, as well as other unreliable priorities.
 
 ## Specification Plans
 
@@ -133,14 +119,14 @@ The following public products will be part of this release.
 ### Runtime
 ---
 - **Description:** Runtime for Validator node
-- **Manager:** <span style="color:blue">Mokhtar</span>
+- **Manager:** Mokhtar
 - **Core Team:**
-  - <span style="color:blue">Mokhtar</span>: Developer
-  - <span style="color:blue">Alex</span>: Developer
-  - <span style="color:blue">Jens</span>: Developer
-  - <span style="color:blue">Martin</span>: Testing
-  - <span style="color:blue">Bedeho</span>: Developer
-  - <span style="color:blue">Jaydip</span>: Devops
+  - **Mokhtar:** Developer
+  - **Alex:** Developer
+  - **Jens:** Developer
+  - **Martin:** Testing
+  - **Bedeho:** Developer
+  - **Jaydip:** Devops
 - **Main repo:** [substrate-runtime-joystream](https://github.com/Joystream/substrate-runtime-joystream)
 - **Current version:** 4
 - **New version:** 5
@@ -148,10 +134,10 @@ The following public products will be part of this release.
 - **Documentation:** NO CHANGE
 - **Legal Review/ToS update:** NO CHANGE
 - **Build/CI system:**
-  - <span style="color:blue">Jaydip</span>: Get CI builds for runtime
+  - **Jaydip:** Get CI builds for runtime
 - **Target Platforms:** NO CHANGE
 - **New/Altered Functionality:**
-  - <span style="color:blue">Mokhtar</span>: Basic membership system:
+  - **Mokhtar:** Basic membership system:
     - Pay for membership signup
     - No working groups for screening or policing
     - Reusing storage for avatar persistence.
@@ -159,7 +145,7 @@ The following public products will be part of this release.
     - Do Validators also have to be members. (will require changing staking
 module)
     - Replace/Update Indices module (account indexing)
-  - <span style="color:blue">Jens</span>, <span style="color:blue">Mokhtar</span>: Basic storage and distribution:
+  - **Jens**, **Mokhtar:** Basic storage and distribution:
     - Roles combined into single staked actor that fully replicates full data
 directory
     - No working group, anyone can enter so long as they pass requirements.
@@ -168,7 +154,7 @@ directory
       - no tranches -(all storage nodes do full replication?)
       - only the object types required in this release
       - very few data object types (which?)
-  - <span style="color:blue">Jens</span>: Basic content directory
+  - **Jens:** Basic content directory
     - controlled by through root, no working group
     - policed through sudo
     - basic publisher profile.
@@ -176,7 +162,7 @@ directory
       - a standalone video clip (podcasts are published)
       - an audio podcast series and episodes
     - All static assets live in storage system
-  - <span style="color:blue">Mokhtar</span>: do something about spam risk, e.g. falt tx fee
+  - **Mokhtar:** do something about spam risk, e.g. falt tx fee
 - **Refactor/Reorganization:**
   - Split the runtime into its own repo, and include a docker script for doing
 reproducible builds. Will be needed for testing/verifying runtime upgrade
@@ -189,18 +175,18 @@ proposals, and first use will be for this next release
 ---
 
 - **Description:** Validator node.
-- **Manager:** <span style="color:blue">Mokhtar</span>
+- **Manager:** **Mokhtar**
 - **Team:**
-  - <span style="color:blue">Mokhtar</span>: Developer
-  - <span style="color:blue">Martin</span>: Testing
-  - <span style="color:blue">Jaydip</span>: Devops
+  - **Mokhtar:** Developer
+  - **Martin:** Testing
+  - **Jaydip:** Devops
 - **Main repo:** [substrate-node-joystream](https://github.com/Joystream/substrate-node-joystream)
 - **Current version:** v0.10.
 - **New version:** v0.10.2 (backward compatible with old nodes/chain (network/p2p/codec
 etc..))
 - **Audit:** NO
 - **Documentation:** NO CHANGE
-- **Legal Review/ToS update:** Yes (<span style="color:blue">Martin</span>)
+- **Legal Review/ToS update:** Yes (**Martin**)
 - **Build/CI system:** NO CHANGE
 - **Target Platforms:**
   - Mac
@@ -216,7 +202,7 @@ etc..))
 - **Deployment/Distribution:**
   - Will be have to be downloaded from GitHub release page, with links being
 distributed relevant tutorials and communications.
-  - <span style="color:blue">Jaydip</span>:
+  - **Jaydip:**
     - Get docker image based builds working
     - Docker image hosted on docker.com public repo + instructions?
     - OSX brew/Ubuntu snap?
@@ -224,20 +210,20 @@ distributed relevant tutorials and communications.
 ### Colossus
 ---
 - **Description:** Combined storage and distribution node.
-- **Manager:** <span style="color:blue">Jens</span>
+- **Manager:** **>Jens**
 - **Team:**
-  - <span style="color:blue">Jens</span>: Developer
-  - <span style="color:blue">Martin</span>: Testing
+  - **Jens:** Developer
+  - **Martin:** Testing
 - **Main repo:** [storage-node-joystream](https://github.com/Joystream/storage-node-joystream)
 - **Current version:** 0.1.
 - **New version:** 0.2.
 - **Audit:** NO
 - **Documentation:** API YES (needed for other devs to understand how to interface with
 it).
-- **Legal Review/ToS update:** Yes (<span style="color:blue">Martin</span>)
+- **Legal Review/ToS update:** Yes (**Martin**)
 - **Build/CI system:** NO CHANGE
 - **Target Platforms:** Linux. Testing required for others.
-- **New/Altered Functionality:** <span style="color:blue">Jens</span>
+- **New/Altered Functionality:** **Jens**
   - This first version is based on the following:
   - for now, hyperdrive for storage & synchronizing (tech underlying Dat)
   - nodejs + expressjs + express-openapi for application facing API.
@@ -255,21 +241,21 @@ distributed relevant tutorials and communications.
 ### Pioneer
 ---
  - **Description:** The user interface for interacting with the platform.
- - **Manager:** <span style="color:blue">Alex</span>
+ - **Manager:** **Alex**
  - **Team:**
-  - <span style="color:blue">Alex</span>: Developer
-  - <span style="color:blue">Mokhtar</span>: Developer
-  - <span style="color:blue">Tomasz</span>: Designer
-  - <span style="color:blue">Martin</span>: Testing
+  - **Alex:** Developer
+  - **Mokhtar:** Developer
+  - **Tomasz:** Designer
+  - **Martin:** Testing
  - **Main repo:** [apps](https://github.com/Joystream/apps)
  - **Current version:** 0.23.29 (inherited from Polkadot Apps)
  - **New version:** 0.2.
  - **Audit:** NO
  - **Documentation:** NO CHANGE
- - **Legal Review/ToS update:** Yes (<span style="color:blue">Martin</span>)
+ - **Legal Review/ToS update:** Yes (**Martin**)
  - **Build/CI system:** NO CHANGE
  - **Target Platforms:** Web
- - **New/Altered Functionality**: <span style="color:blue">Alex</span>
+ - **New/Altered Functionality**: **Alex**
   - Update name of application:
     - GitHub repo name
     - Browser title bar
@@ -328,24 +314,24 @@ Substrate events where a current user was an origin of tx.
 - **Description:** We conduct an actual testnet with ourselves and key community members as
 participants.
 - **Deadline:** 29. March
-- **Manager:** <span style="color:blue">Martin</span>
+- **Manager:** **Martin**
 - **Team:**
-  - <span style="color:blue">Mokhtar</span>: Developer
-  - <span style="color:blue">Jaydip</span>: DevOps
+  - **Mokhtar:** Developer
+  - **Jaydip:** DevOps
 - **Test specification:**
-  - <span style="color:red">Please rewrite more clearly</span>
+  - _Please rewrite more clearly_
 
 ### Runtime Upgrade
 
 - **Description:** Submit proposal to change to new image, and have council pass that proposal.
 - **Deadline:** 02. April
-- **Manager:** <span style="color:blue">Martin</span>
+- **Manager:** **Martin**
 - **Team:**
-  - <span style="color:blue">Martin</span>: Writing
-  - <span style="color:blue">Mokhtar</span>: Developer
-  - <span style="color:blue">Tomasz</span>: Designer
+  - **Martin:** Writing
+  - **Mokhtar:** Developer
+  - **Tomasz:** Designer
 - **Time line:**
-  - <span style="color:red">Please rewrite more clearly</span>
+  - _Please rewrite more clearly_
 
 ## Go-To-Market
 
@@ -355,35 +341,35 @@ participants.
 announcement, the following incentive campaign is in place to achieve key results for service
 providers. Policy would be
   - Validator: 30$ per week -> 0.03C per block
-  - Council Member: 5$ for seat, 5$ for vote
-  - Storage: $0.1/GB per day (depends on whether anyone can upload)
-- **Manager:** <span style="color:blue">Martin</span>
+  - Council Member: **8$** for seat, **5$** for vote on runtime upgrade(s)
+  - Storage: **$10** per week, with **$0.025/GB** per week
+- **Manager:** **Martin**
 - **Team:**
-  - <span style="color:blue">Martin</span>: Manager
-  - <span style="color:blue">Bedeho</span>: ElPassion Manager
-  - <span style="color:blue">Mokhtar</span>: Developer
-  - <span style="color:blue">Tomasz</span>: Designer
-  - <span style="color:blue">Jaydip</span>: Community manager/Devops
+  - **Martin:** Manager
+  - **Bedeho:** ElPassion Manager
+  - **Mokhtar:** Developer
+  - **Tomasz:** Designer
+  - **Jaydip:** Community manager/Devops
 - **Tasks:**
-  - <span style="color:blue">Bedeho</span>, <span style="color:blue">Tomasz</span>: Update Joystream.org with new testnet summary information
+  - **Bedeho**, **Tomasz:** Update Joystream.org with new testnet summary information
    - New fields about new state
      - Number of members (perhaps even actual names?)
      - Number of storage providers
      - Total amount of storage used
      - Total amount of content items published
    - Better representation about election cycle system, more clearly need to represent the multistaged nature, with a countdown to act, and perhaps why, and also a CTA to actually act.
-   - New list of roles, with active ones emphasied
+   - New list of roles, with active ones emphasised
    - New section for next testnet, with state there <== needs name
-  - <span style="color:blue">Mokhtar</span>: Update backend infrastructure to support new life Athens web based summary
-  - <span style="color:blue">Martin</span>: Update or write tutorials for how to participate in roles on Github
+  - **Mokhtar:** Update backend infrastructure to support new life Athens web based summary
+  - **Martin:** Update or write tutorials for how to participate in roles on Github
     - Validator (systemd setup, fine tuning linux, inspiration: https://kb.certus.one/)
     - Storage Provider
-  - <span style="color:blue">Martin</span>: Write & publish blog posts
+  - **Martin:** Write & publish blog posts
     - [Runtime upgrades vs forks](runtime-upgrades-vs-forks)
     - [Announcing Athens Testnet](announcing-athens-testnet)
     - [Athens Incentive Structure](athens-incentive-structure)
     - [Athens Released](athens-released)
-  - <span style="color:blue">Jaydip</span>: Tech support/online presence
+  - **Jaydip:** Tech support/online presence
     - Monitor tlgrm, RC, (after trust established, twtr and reddit?)
 
 ### Tutorials
@@ -392,7 +378,7 @@ providers. Policy would be
 
 - **Description:** Step by step guide for how to setup and run a validator node, and claim reward
 - **CTA:** Go and setup your node
-- **Author:** <span style="color:blue">Martin</span>
+- **Author:** **Martin**
 - **Distribution:** Github?
 - **Assets:** NONE
 
@@ -400,7 +386,7 @@ providers. Policy would be
 
 - **Description:** Step by step guide for how to setup and run a storage provider node, and claim reward
 - **CTA:** Go and setup your node
-- **Author:** <span style="color:blue">Jens</span>,<span style="color:blue">Martin</span>
+- **Author:** **Jens**,**Martin**
 - **Distribution:** Github?
 - **Assets:** NONE
 
@@ -411,7 +397,7 @@ providers. Policy would be
 - **Description:** Somewhat technical blog about what these are, what they enable, and how we
 are doing them.
 - **CTA:** Educational+hiring credibility
-- **Author:** <span style="color:blue">Mokhtar</span>,<span style="color:blue">Martin</span>
+- **Author:** **Mokhtar**,**Martin**
 - **Distribution:** Twtr, Tlgrm, Reddit, RC + polkadot forum(s)
 - **Assets:** Cover + some new pagebreakers - <Spartan w/sword defeating enemy w/fork>
 
@@ -422,7 +408,7 @@ showings its logo, and a scheduled date (we are not in full control), once featu
 Telling people what the next sequence of events are, including future messages, future points in
 time they must act.
 - **CTA:** What action can people do, and how
-- **Author:** <span style="color:blue">Martin</span>
+- **Author:** **Martin**
 - **Distribution:** TTRR
 - **Assets:** Cover + some new pagebreakers - <athenian owlcould be featured unless we want
 to use this as “main” athens logo. >
@@ -431,7 +417,7 @@ to use this as “main” athens logo. >
 
 - **Description:** Incentive structure and changes made for Athens + lessons learned
 - **CTA:** Roles to take, and why
-- **Author:** <span style="color:blue">Martin</span>
+- **Author:** **Martin**
 - **Distribution:** TTRR
 - **Assets:** Cover + some new pagebreakers - <something similar to the Spartan one, but with
 new logo and storage provider role>
@@ -441,7 +427,7 @@ new logo and storage provider role>
 - **Description:** TL;DR of previous posts with links + Full update on howto, with an emphasis on
 new roles
 - **CTA:** Sign up now
-- **Author:** <span style="color:blue">Martin</span>
+- **Author:** **Martin**
 - **Distribution:** TTRR+newsletter
 - **Assets:** Cover + some new pagebreakers - < Athens logo>
 
@@ -450,43 +436,43 @@ new roles
 ### Hosted Joystream Pioneer
 
 - **Description:** Host a version of Joystream Pioneer on joystream.org + others?
-- **Manager:** <span style="color:blue">Jaydip</span>
-- **DevOps:** <span style="color:blue">Jaydip</span>
+- **Manager:** **Jaydip**
+- **DevOps:** **Jaydip**
 - **Repo:** Aim for static build of pioneer repo (similar to polkadot-js apps deploymnet)
 - **Team:**
-  - <span style="color:blue">Jaydip</span>
+  - **Jaydip**
 - **Tasks:**
   - Reuse existing linode server or deploy to heroku for example (autodeploy o master branch merge)?
 
 ### Hosted Joystream Storage Node
 
 - **Description:** A storage node controlled by us, serving as fallback
-- **Manager:** <span style="color:blue">Jens</span>
-- **DevOps:** <span style="color:blue">Jens</span>
+- **Manager:** **Jens**
+- **DevOps:** **Jens**
 - **Repo:** [storage-node-joystream](https://github.com/Joystream/storage-node-joystream)
 - **Team:**
-  - <span style="color:blue">Jens</span>
+  - **Jens**
 
 ### Storage & distribution error endpoint
 
 - **Description:** Reporting endpoint where any user of the data storage and distribution protocol can signal peer failures, will be deployed on error.joystream.org.
-- **Manager:** <span style="color:blue">Alex</span>
-- **DevsOps:** <span style="color:blue">Mokhtar</span>
-- **Repo:** TBD by <span style="color:blue">Alex</span>
+- **Manager:** **Alex**
+- **DevsOps:** **Mokhtar**
+- **Repo:** TBD by **Alex**
 - **Team:**
-  - <span style="color:blue">Alex</span>.
-  - <span style="color:blue">Mokhtar</span>.
+  - **Alex**.
+  - **Mokhtar**.
 - **Note:**
   - Check out Logstash/Kibana/Mixpanel/Splunk
 
 ### Faucet service backend
 
 - **Description:** Free token dispenser
-- **Manager:** <span style="color:blue">Mokhtar</span>
-- **DevOps:** <span style="color:blue">Mokhtar</span>
+- **Manager:** **Mokhtar**
+- **DevOps:** **Mokhtar**
 - **Repo (private):** [substrate-faucet](https://github.com/Joystream/substrate-faucet)
 - **Team:**
-  - <span style="color:blue">Mokhtar</span>
+  - **Mokhtar**
 - **Tasks:**
   - Shouldn’t need much changes on backend, if using google captcha in pioneer.
   - Update README with instructions on how to deploy backend.
@@ -497,10 +483,10 @@ new roles
 ### Payout Tool
 
 - **Description:** Tool to compute payouts to relevant parties on testnet
-- **Manager:** <span style="color:blue">Martin</span>
+- **Manager:** **Martin**
 - **Repo (private):** [testnet-payout-scripts](https://github.com/Joystream/testnet-payout-scripts)
 - **Team:**
-  - <span style="color:blue">Martin</span>
+  - **Martin**
 - **Tasks:**
   - Update to cover storage providers
 
@@ -509,20 +495,20 @@ new roles
 ### Payouts
 
 - **Description:** Conduct regular payouts
-- **Manager:** <span style="color:blue">Martin</span>
+- **Manager:** **Martin**
 - **Team:**
-  - <span style="color:blue">Martin</span>
+  - **Martin**
 - **Schedule:**
-  - Storage and Validator get payouts every fifth day
-  - Counil gets one time payout after council upgrade
+  - Storage and Validator get payouts mondays at ~1100GMT
+  - Counil gets payouts ~10:00GMT day after election and, if applicable, vote.
 
 ### Support
 
 - **Description:** Provide support to users enaging with testnet functionality and campaigns
-- **Manager:** <span style="color:blue">Jaydip</span>
+- **Manager:** **Jaydip**
 - **Team:**
-  - <span style="color:blue">Jaydip</span>
-  - <span style="color:blue">Martin</span>
+  - **Jaydip**
+  - **Martin**
 - **Duration:**
   - Very high availability in the week following releases
   - No more than 24 hour lag in response to queries after that
@@ -533,8 +519,6 @@ new roles
 
 ## Milestones
 
-<span style="color:blue">Martin</span> puts on Github.
-
 1. 29 March: Athens Runtime Testnet
 2. 02 April: Runtime Upgrade
 3. Update website?

BIN
testnets/athens/athens-testnet-headline.png


+ 0 - 11
testnets/athens/athens-testnet-headline.svg

@@ -1,11 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<svg width="592px" height="74px" viewBox="0 0 592 74" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
-    <!-- Generator: Sketch 53.2 (72643) - https://sketchapp.com -->
-    <title>Athens Testnet</title>
-    <desc>Created with Sketch.</desc>
-    <g id="Headlines" stroke="none" stroke-width="1" fill="none" fill-rule="evenodd" font-family="HelveticaNeue-UltraLight, Helvetica Neue" font-size="100" font-weight="200">
-        <text id="Athens-Testnet" fill="#000000">
-            <tspan x="2.5" y="72">Athens Testnet</tspan>
-        </text>
-    </g>
-</svg>

+ 0 - 264
testnets/release-document-template.md

@@ -1,264 +0,0 @@
-<p align="center"><img width=200px src="testnet-placeholder-logo.svg"></p>
-<p align="center"><img src="testnet-placeholder-headline.svg"></p>
-
-<div align="center">
-  <h3>
-    <a href="#">
-      Specification
-    </a>
-    <span> | </span>
-    <a href="#">
-      OKRs
-    </a>
-    <span> | </span>
-    <a href="#">
-      Products
-    </a>
-    <span> | </span>
-    <a href="#">
-      Milestones
-    </a>
-  </h3>
-</div>
-
-# Table of contents
-
-- [Overview](#overview)
-- [Release Meetings](#release-meetings)
-- [Specification](#specification)
-- [GitHub Projects](#github-projects)
-- [OKR results](#okr-results)
-- [Release Plan](#release-plan)
-  - [Manager](#manager)
-  - [Release Date](#release-date)
-  - [OKRs](#okrs)
-  - [Constraints](#constraints)
-  - [Risks](#risks)
-  - [Deployment](#deployment)
-  - [Specification Plans](#specification-plans)
-  - [Products](#products)
-  - [Events](#events)
-  - [Go-To-Market](#go-to-market)
-    - [Paid Roles](#paid-roles)
-    - [Tutorials](#tutorials)
-    - [Messages](#messages)
-  - [Public Infrastructure](#public-infrastructure)
-  - [Internal Infrastructure and Tools](#internal-infrastructure-and-tools)
-  - [Internal Operations](#internal-operations)
-  - [Milestones](#milestones)
-
-# Overview
-
-Athens is the third Joystream testnet, and it is scheduled for release
-
-### `Date`, `Time` (`Time Zone`)
-
-# Release Meetings
-
-| Date            | Link          |
-| -------------   | ------------- |
-| NA              | x              |
-
-#  Specification
-
-[Specification](...)
-
-# GitHub Projects
-
-The current set of relevant GitHub projects are
-
-- [X Release](https://github.com/orgs/Joystream/projects/X)
-
-# OKR results
-
-Will be available on measurement deadline, will be done by
-
-- **`Name`**
-
-# Release Plan
-
-`A release plan is a planning document used in a process, her, its not meant to be kept in synch with ongoing efforts after this initial planning stage.`
-
-## Manager
-
-**`Name`**
-
-## Release Date
-
-`Date`, `Time` (`Time Zone`)
-
-## OKRs
-
-### Objective: `objective`
-- **KR Measurement Deadline**: 1 week after  launch
-- **Key Results**:
-#### 1. `...`
-
-## Constraints
-
-`List of constraints`
-
-## Risks
-
-`List of risks`
-
-## Specification Plans
-
-`Whether there is going to be a separate spec`
-
-## Deployment
-
-`How to do upgrade, specifically on-chain upgrade of runtime, with or without migration, or new genesis block and thus network`
-
-## Products
-
-The following public products will be part of this release.
-
-### Runtime
----
-- **Description:** Runtime for Validator node
-- **Manager:** <span style="color:blue">Mokhtar</span>
-- **Core Team:**
-  - `Name of person`: `Role`
-- **Main repo:** [`repo name`](...)
-- **Current version:** `..`
-- **New version:** `..`
-- **Audit:** `..`
-- **Documentation:** `..`
-- **Legal Review/ToS update:** `..`
-- **Build/CI system:**
-  - <span style="color:blue">Jaydip</span>: Get CI builds for runtime
-- **Target Platforms:** NO CHANGE
-- **New/Altered Functionality:**
-  - <span style="color:blue">Mokhtar</span>: Basic membership system:
-    - `...`
-- **Refactor/Reorganization:**
-  - Split the runtime into its own repo, and include a docker script for doing
-reproducible builds. Will be needed for testing/verifying runtime upgrade
-proposals, and first use will be for this next release
-- **New Key User Stories:** NONE
-- **Deployment/Distribution:**
-    - Will be voted in through an upgrade proposal in council, see Events section for how.
-
-
-## Events
-
-### Athens Runtime Testnet
-
-- **Description:** We conduct an actual testnet with ourselves and key community members as
-participants.
-- **Deadline:** 29. March
-- **Manager:** <span style="color:blue">Martin</span>
-- **Team:**
-  - <span style="color:blue">Mokhtar</span>: Developer
-  - <span style="color:blue">Jaydip</span>: DevOps
-- **Test specification:**
-  - <span style="color:red">Please rewrite more clearly</span>
-
-
-## Go-To-Market
-
-### Paid Roles
-
-- **Description:** During the lifetime of the testnet, until next upgrade or network or discretionary
-announcement, the following incentive campaign is in place to achieve key results for service
-providers. Policy would be
-  - Validator: 30$ per week -> 0.03C per block
-  - Council Member: 5$ for seat, 5$ for vote
-  - Storage: $0.1/GB per day (depends on whether anyone can upload)
-- **Manager:** <span style="color:blue">Martin</span>
-- **Team:**
-  - <span style="color:blue">Martin</span>: Manager
-  - <span style="color:blue">Bedeho</span>: ElPassion Manager
-  - <span style="color:blue">Mokhtar</span>: Developer
-  - <span style="color:blue">Tomasz</span>: Designer
-  - <span style="color:blue">Jaydip</span>: Community manager/Devops
-- **Tasks:**
-  - <span style="color:blue">Bedeho</span>, <span style="color:blue">Tomasz</span>: Update Joystream.org with new testnet summary information
-   - New fields about new state
-     - Number of members (perhaps even actual names?)
-     - Number of storage providers
-     - Total amount of storage used
-     - Total amount of content items published
-   - Better representation about election cycle system, more clearly need to represent the multistaged nature, with a countdown to act, and perhaps why, and also a CTA to actually act.
-   - New list of roles, with active ones emphasied
-   - New section for next testnet, with state there <== needs name
-  - <span style="color:blue">Mokhtar</span>: Update backend infrastructure to support new life Athens web based summary
-  - <span style="color:blue">Martin</span>: Update or write tutorials for how to participate in roles on Github
-    - Validator (systemd setup, fine tuning linux, inspiration: https://kb.certus.one/)
-    - Storage Provider
-  - <span style="color:blue">Martin</span>: Write & publish blog posts
-    - [Runtime upgrades vs forks](runtime-upgrades-vs-forks)
-    - [Announcing Athens Testnet](announcing-athens-testnet)
-    - [Athens Incentive Structure](athens-incentive-structure)
-    - [Athens Released](athens-released)
-  - <span style="color:blue">Jaydip</span>: Tech support/online presence
-    - Monitor tlgrm, RC, (after trust established, twtr and reddit?)
-
-### Tutorials
-
-#### How to be a Validator
-
-- **Description:** Step by step guide for how to setup and run a validator node, and claim reward
-- **CTA:** Go and setup your node
-- **Author:** <span style="color:blue">Martin</span>
-- **Distribution:** Github?
-- **Assets:** NONE
-
-## Public Infrastructure
-
-### Hosted Joystream Pioneer
-
-- **Description:** Host a version of Joystream Pioneer on joystream.org + others?
-- **Manager:** <span style="color:blue">Jaydip</span>
-- **DevOps:** <span style="color:blue">Jaydip</span>
-- **Repo:** Aim for static build of pioneer repo (similar to polkadot-js apps deploymnet)
-- **Team:**
-  - <span style="color:blue">Jaydip</span>
-- **Tasks:**
-  - Reuse existing linode server or deploy to heroku for example (autodeploy o master branch merge)?
-
-
-## Internal Infrastructure and Tools
-
-### Payout Tool
-
-- **Description:** Tool to compute payouts to relevant parties on testnet
-- **Manager:** <span style="color:blue">Martin</span>
-- **Repo (private):** [testnet-payout-scripts](https://github.com/Joystream/testnet-payout-scripts)
-- **Team:**
-  - <span style="color:blue">Martin</span>
-- **Tasks:**
-  - Update to cover storage providers
-
-## Internal Operations
-
-### Payouts
-
-- **Description:** Conduct regular payouts
-- **Manager:** <span style="color:blue">Martin</span>
-- **Team:**
-  - <span style="color:blue">Martin</span>
-- **Schedule:**
-  - Storage and Validator get payouts every fifth day
-  - Counil gets one time payout after council upgrade
-
-### Support
-
-- **Description:** Provide support to users enaging with testnet functionality and campaigns
-- **Manager:** <span style="color:blue">Jaydip</span>
-- **Team:**
-  - <span style="color:blue">Jaydip</span>
-  - <span style="color:blue">Martin</span>
-- **Duration:**
-  - Very high availability in the week following releases
-  - No more than 24 hour lag in response to queries after that
-- **Channels:**
-  - Telegram
-  - Reddit
-  - RocketChat
-
-## Milestones
-
-1. `...`
-2. `...`

BIN
testnets/testnet-logo.png


+ 0 - 11
testnets/testnet-placeholder-headline.svg

@@ -1,11 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<svg width="460px" height="74px" viewBox="0 0 460 74" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
-    <!-- Generator: Sketch 53.2 (72643) - https://sketchapp.com -->
-    <title>&lt;* Testnet&gt;</title>
-    <desc>Created with Sketch.</desc>
-    <g id="Headlines" stroke="none" stroke-width="1" fill="none" fill-rule="evenodd" font-family="HelveticaNeue-UltraLight, Helvetica Neue" font-size="100" font-weight="200">
-        <text id="&lt;*-Testnet&gt;" fill="#000000">
-            <tspan x="-3.65" y="72">&lt;* Testnet&gt;</tspan>
-        </text>
-    </g>
-</svg>

+ 0 - 14
testnets/testnet-placeholder-logo.svg

@@ -1,14 +0,0 @@
-<?xml version="1.0" encoding="UTF-8"?>
-<svg width="424px" height="171px" viewBox="0 0 424 171" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
-    <!-- Generator: Sketch 53.2 (72643) - https://sketchapp.com -->
-    <title>Group</title>
-    <desc>Created with Sketch.</desc>
-    <g id="logoes" stroke="none" stroke-width="1" fill="none" fill-rule="evenodd">
-        <g id="Group">
-            <rect id="Rectangle" fill="#D8D8D8" x="0" y="0" width="424" height="171" rx="8"></rect>
-            <text id="Testnet-Logo" font-family="HelveticaNeue-UltraLight, Helvetica Neue" font-size="60" font-weight="200" fill="#000000">
-                <tspan x="59.43" y="107">Testnet Logo</tspan>
-            </text>
-        </g>
-    </g>
-</svg>