diff --git a/README.md b/README.md
index a72b56ab51..b2eb7ccfb4 100644
--- a/README.md
+++ b/README.md
@@ -29,16 +29,15 @@
Helpdesk
-
-# Table of contents
+Table of Contents
+=================
- [Overview](#overview)
- [Contribute](#contribute)
@@ -51,7 +50,7 @@
- [Why is this on Github?](#why-is-this-on-github)
- [Meetings](#meetings)
- [Daily standup](#daily-standup)
- - [Monday all-hands](#monday-all-hands)
+ - [Tuesday all-hands](#tuesday-all-hands)
- [Release meeting](#release-meeting)
- [OKR System](#okr-system)
- [Assignment](#assignment)
@@ -63,14 +62,14 @@
- [Branding](#branding)
- [Testnet Directory](#testnet-directory)
- [Roles](#roles)
- - [Release Manager](#release-manager)
- - [Specification Lead and Committee](#specification-lead-and-committee)
+ - [Tracking Issues](#tracking-issues)
+ - [Milestones](#milestones)
- [Step-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.
+This landing repo is intended to be the best starting place to get a coherent view of how information is organised in this GitHub organization.
# Contribute
@@ -84,7 +83,7 @@ The central repos will have multiple members of the core team with write access,
The core team, maintainers and outside contributors are encouraged to follow these general guidelines when contributing to the code repositories:
* All contributions should be via pull requests.
-* Do not create arbitrary branches or push directly to the central repo `master` or `development` branches
+* Do not create arbitrary branches or push directly to the central repo `master` or `development` branches.
* Do not force push branches.
* Avoid rebasing branches of open PRs to help preserve conversation history.
* Authors must always request a review for their PRs, Exception: It does not alter any logic (e.g. comments, dependencies, docs, file organisation), then it may merged once CI checks are complete.
@@ -93,13 +92,13 @@ The core team, maintainers and outside contributors are encouraged to follow the
* When the maintainer is opening a PRs they must still request review from a core team member.
Each repository may have contributing guidelines detailed in their README files.
-Maintainer must ensure this contribution section is linked to as the base guideline.
+The maintainer must ensure this contribution section is linked to as the base guideline.
-Documentation, Project management and other or non-code repositories should try to follow similar PR etiquette if it makes sense but exceptions can be made as changes usually don't require the same level of review.
+Documentation, project management and other or non-code repositories should try to follow similar PR etiquette if it makes sense but exceptions can be made as changes usually don't require the same level of review.
# Repository Index
-This is the set of key repos that
+This is the set of key repos to which this document refers:
| Repo | Description | Maintainer |
| :------------- | :------------- | :-----------: |
@@ -122,32 +121,29 @@ Until the Joystream mainnet goes live, a sequence of test networks will be rolle
[Acropolis](/testnets/acropolis/README.md)
-
## Past Testnets
| Network | Started | Ended | Release Plan |
| ------------- | ------------- | ----- | ----- |
| Athens | 17.04.19 | 24.06.19 | [Link](/testnets/athens/README.md) |
-| Sparta | 28.02.19 | 29.03.19 | NA |
-| Mesopotamia | 21.12.18 | 28.02.19 | NA |
+| Sparta | 28.02.19 | 29.03.19 | N/A |
+| Mesopotamia | 21.12.18 | 28.02.19 | N/A |
`
+## Objective: ``
- **Active from:** ``
- **KR Measurement Deadline**: ``
- **Tracked**: ``
@@ -277,135 +273,70 @@ The template used for recording and tracking OKRs has the following form:
### Branding
-All releases have the following branding materials, which should be summarised in a markdown _Branding Document_
+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).
+- **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 if we will also move forward in time (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.
+- **Goal:** A brief 100-200 word text about the 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
+All releases should have a corresponding _release directory_ in the `/testnets` directory of this repo, and it should have the following structure:
-- `RELEASE_NAME`
+- `release_name`
- `README.md`: Release document.
- - **WIP**`specification.md`: Testnet specification.
+ - `specification.md`: Testnet specification.
- `/branding`: A directory which includes a branding document and related assets, as described in the branding [section](#branding).
### Roles
#### Release Manager
-Each release is directed by a _Release Manager_ (**RM**) who is responsible for
+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.
+ - Conduct weekly status meetings (Monday), for each [Tracking Issue](#tracking-issues) of the release.
+ - Based on this information, set a weekly tracking score for each KR to be presented and discussed with the team as part of the [Tuesday all-hands](#tuesday-all-hands).
- Preparing all administrative pull requests for the release on this repo.
+ - Follow up the Release [Milestones](#milestones)
-#### Leads
+### Tracking Issues
-A [release plan](/testnets/#release-plan-template) will consist of a set of projects, each with a corresponding lead, these are referred to as the _leads_.
+A Tracking Issue is a GitHub issue which **evolves**, and at any given time holds a list of TODO items, with a corresponding completion status and and possibly responsibility indicator (i.e. each item has one responsible actor). TODO items are grouped into Tracking Issues based on what most deeply facilitates effective collaboration and progress tracking.
-#### Specification Lead and Committee
+- Every Monday, each Tracking Issue will be discussed in a video meeting between all assigned team members and the Release Manager.
+- These meetings should be highly focused, and kept at a reasonably high level.
+- If a discussion gets to deep, the **RM** can request that the relevant participants schedule a new meeting to address the issue.
+- The Release Manager will then update the Tracking Issue if necessary by changing/adding/removing/reassigning tasks, and checking off concluded tasks.
+- A concise summary of the meeting shall be added as a comment.
-The specification lead is responsible for moving the specification process forward, and the committee is anyone who is expected to contribute.
+### Milestones
-**WIP: we need to connect this to broader information about our specification work, but that is not done yet**
+As part of the Release Plan, a set of Milestones are set, with a "target date". Similar to the concept of [Tracking Issues](#tracking-issues), the "Live Milestones" is a GitHub issue which **evolves**. Experience have shown, that during a release cycle:
+- we may require adjusting the target date(s)
+- we may want to add or remove certain Milestones
+- we may want to adjust the scope of certain Milestones
### 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.
-
-### Step-by-step Process
-
-This whole process should take no more than **7** working 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](/testnets), 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
+In addition to the weekly follow-up up meetings addressed above, each release cycle includes the more formal meetings listed below.
-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.
+- `Launch Meeting`
+- `User Stories Meeting`
+- `Release Plan Finalization Meeting]`
+- `Release Checklist Meeting`
+- `Lessons Learned`
-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.
+The **RM** is responsible for scheduling, conducting and taking minutes. Go [here](/meetings) to read about previously held, and scheduled release meetings.
-12. Release planning meetings are conducted on a per-need basis, typically more frequently as the release date approaches.
+### Step by Step Process
+TODO
The line between bureaucracy and rigour is 1px thin, but what are we to do? :pray:
-# Table of contents
+Table of Contents
+=================
+
- [Meeting Archiving](#meeting-archiving)
- [Archive Index](#archive-index)
- [Itinerary Template](#itinerary-template)
+ - [Short Meeting Identifier](#short-meeting-identifier)
+
+
+
# Meeting Archiving
@@ -23,11 +29,14 @@ This is the index of past meetings with itineraries, they should all be stored i
| Meeting Identifier | Invitation sent | Scheduled (held) | Itinerary and Minutes | Notes |
| :-----------------------------------------: | :---------------:|-----------------------| :------------------------------------------------: | :----------------------------:|
-| Acropolis Launch Meeting | 24.04.19 | 26.04.19-12:15GMT+2 (x) | [link](../meetings/acropolis#launch-meeting) | - |
-| Acropolis User Stories Meeting | 26.04.19 | 02.05.19-12:15GMT+2 (x) | [link](../meetings/acropolis#user-stories-meeting) | Rescheduled from 30.04 |
-| Acropolis Release Plan Finalization Meeting | 06.05.19 | 09.05.19-11:15GMT+2 (x) | [link](../meetings/acropolis#release-plan-finalisation-meeting) | Two working days not feasible |
-| Acropolis Release Plan Milestone Evaluation Meeting | 10.06.19 | 11.06.19-11:15GMT+2 (x) | [link](../meetings/acropolis##release-plan-milestone-evaluation-meeting) | Re-evaluation of Milestones due to changing circumstances |
-| Acropolis - Lessons Learned | 01.07.19 | 02.07.19-11:15GMT+2 (x) | [link](../meetings/acropolis##lessons-learned) | Lessons learned after release |
+| Rome Release Plan Finalization Meeting | 19.08.19 | 20.08.19-11:15GMT+2 (x) | [link](../meetings/rome#release-plan-finalization-meeting) |- |
+| Rome User Stories Meeting | 10.07.19 | 16.07.19-11:00GMT+2 (x) | [link](../meetings/rome#user-stories-meeting) | Due to complexity and logistics, the meeting took place over several days |
+| Rome Launch Meeting | 09.07.19 | 09.07.19-11:30GMT+2 (x) | [link](../meetings/rome#launch-meeting) | - |
+| Acropolis - Lessons Learned | 01.07.19 | 02.07.19-11:15GMT+2 (x) | [link](../meetings/acropolis##lessons-learned) | Lessons learned after release |
+| Acropolis Release Plan Milestone Evaluation Meeting | 10.06.19 | 11.06.19-11:15GMT+2 (x) | [link](../meetings/acropolis##release-plan-milestone-evaluation-meeting) | Re-evaluation of Milestones due to changing circumstances |
+| Acropolis Release Plan Finalization Meeting | 06.05.19 | 09.05.19-11:15GMT+2 (x) | [link](../meetings/acropolis#release-plan-finalization-meeting) | Two working days not feasible |
+| Acropolis User Stories Meeting | 26.04.19 | 02.05.19-12:15GMT+2 (x) | [link](../meetings/acropolis#user-stories-meeting) | Rescheduled from 30.04 |
+| Acropolis Launch Meeting | 24.04.19 | 26.04.19-12:15GMT+2 (x) | [link](../meetings/acropolis#launch-meeting) | - |
# Itinerary Template
diff --git a/meetings/rome/README.md b/meetings/rome/README.md
new file mode 100644
index 0000000000..c3a623e214
--- /dev/null
+++ b/meetings/rome/README.md
@@ -0,0 +1,605 @@
+Table of contents
+=================
+
+
+- [Planned Meetings](#planned-meetings)
+ - [Release Checklist Meeting](#release-checklist-meeting)
+ - [Agenda](#agenda)
+ - [Minutes](#minutes)
+ - [Lessons Learned](#lessons-learned)
+ - [Agenda](#agenda-1)
+ - [Minutes](#minutes-1)
+- [Conducted Meetings](#conducted-meetings)
+ - [Launch Meeting](#launch-meeting)
+ - [Agenda](#agenda-2)
+ - [Minutes](#minutes-2)
+ - [User Stories Meeting](#user-stories-meeting)
+ - [Agenda](#agenda-3)
+ - [Minutes](#minutes-3)
+ - [Release Plan Finalization Meeting](#release-plan-finalization-meeting)
+ - [Agenda](#agenda-4)
+ - [Minutes](#minutes-4)
+
+
+# Planned Meetings
+
+## Release Checklist Meeting
+
+- **ID:** `Rome Release Checklist Meeting`
+- **Date:** `dd.mm.yy`
+- **Starts:** `hh:mm GMT+2`
+- **Scheduled Duration:** `min`
+- **Venue:** `ZOOM`
+- **Lead**: `NA`
+- **Minutes**: `NA`
+- **Participants**:
+ - `name1`
+ - ...
+
+### Agenda
+#### Item 1
+1. Review the [Release Checklist](../../testnet#release-checklist) draft, and compare to the release plan.
+2. Land a final Release Checklist, that contains all items, and sorted it in order of deployment.
+
+
+### Minutes
+**Started at:** `hh:mm GMT+2`
+**Present:**
+ - `name1`
+ - ...
+
+#### Item 1
+...
+
+**Other topics raised:**
+...
+
+**Ended at:** `hh:mm GMT+2`
+
+
+---
+
+## Lessons Learned
+
+- **ID:** `Rome Lessons Learned`
+- **Date:** `dd.mm.yy`
+- **Starts:** `hh:mm GMT+2`
+- **Scheduled Duration:** `min`
+- **Venue:** `ZOOM`
+- **Lead**: `NA`
+- **Minutes**: `NA`
+- **Participants**:
+ - `name1`
+ - ...
+
+### Agenda
+#### Item 1
+...
+
+
+### Minutes
+**Started at:** `hh:mm GMT+2`
+**Present:**
+ - `name1`
+ - ...
+
+#### Item 1
+...
+
+**Other topics raised:**
+...
+
+**Ended at:** `hh:mm GMT+2`
+
+# Conducted Meetings
+
+## Launch Meeting
+
+- **ID:** `Rome Launch Meeting`
+- **Date:** `10.07.19`
+- **Starts:** `11:30 GMT+2`
+- **Scheduled Duration:** `45min`
+- **Venue:** `ZOOM`
+- **Lead**: `Martin`
+- **Minutes**: `Martin`
+- **Participants**:
+ - `Alex`
+ - `Bedeho`
+ - `Martin`
+ - `Mokhtar`
+
+### Agenda
+#### Item 1
+Discuss draft Rome [release plan](../../testnets/rome).
+
+#### Item 2
+Discuss draft [release OKR](/okrs#release-okrs).
+
+#### Item 3
+Schedule [user stories meeting](#user-stories-meeting)
+
+### Minutes
+**Started at:** `11:30 GMT+2`
+**Present:**
+ - `Alex`
+ - `Bedeho`
+ - `Martin`
+ - `Mokhtar`
+
+#### Item 1
+1. Went through the draft Release plan point by point
+2. Points that were unclear, inaccurate, missing or wrong, was corrected or marked for change.
+
+#### Item 2
+1. Martin presented a draft OKR, with an emphasis on a proposed new way of making, tracking and grading the KRs using github issues, as discussed in the [Acropolis Lessons Learned Meeting](../acropolis#lessons-learned).
+ - In practice, it meant breaking down each KR into tasks
+ - The tasks would be sorted by the affected parties/repos, and a checkbox would accompany each task.
+ - Each task could (optionally) be assigned a weighting, to get an objective tracking of the progress.
+ - Each KR issue would also include an objective and pre-defined formulae for finally grading the KR. This would not necessarily be mapped to the same tasks.
+ - Each Monday, all affected parties would have a meeting, evaluating progress and checking off completed tasks.
+ - A summary of that weeks meeting, alongside a tracking grade, would be added as comment by the release manager.
+ - This summary would be presented on the [Weekly All Hands](https://github.com/Joystream/joystream#monday-all-hands), which would be moved to Tuesday.
+
+2. The general sentiment was that the concept seemed like an improvement in certain areas, but the presented draft was not sufficient to convince all attendees that it sufficiently addressed the problems with the old release OKR system.
+
+3. Attendees shall present proposals to what the KRs should cover.
+
+
+#### Item 3
+
+This was not addresssed.
+
+**Other topics raised:**
+NA
+
+**Ended at:** `15:00 GMT+2`
+
+---
+
+## User Stories Meeting
+
+- **ID:** `Rome User Stories Meeting`
+- **Date:** `16.07.19`
+- **Starts:** `11:00 GMT+2`
+- **Scheduled Duration:** `1h30min`
+- **Venue:** `ZOOM`
+- **Lead**: `Martin`
+- **Minutes**: `Martin`
+- **Participants**:
+ - `Alex`
+ - `Bedeho`
+ - `Martin`
+ - `Mokhtar`
+
+### Agenda
+
+Review and discuss Users Stories.
+Note that during the meeting, it was decided to change the order of discussion due to time constraints. These changes are reflected below.
+
+---
+
+#### 1. General Signup
+
+NB1: provider refers to either storage provider or distributor.
+
+NB2: These stories are kind of hand wavy. Many of the stories may be better suited off chain, e.g. coordinated through a server run by conductor. But it remains to be seen.
+
+##### As a prospective provider I want to
+- see terms associated with existing providers roles
+- see terms associated with open positions for new roles
+- apply to an open position with one click
+- one click download each auto generated key (stash, controller, session) for each role applied to
+- get notified if accepted into a position
+- see list of all positions I have occupied now and prior, and corresponding payouts, and circumstances of leaving.
+- get notified if slashed
+- get notified if evicted
+- leave a role
+
+
+
+##### As a Conductor I want to
+- add an open position with given terms
+- close an open position
+- slash a provider from a position
+- evict a provider from a position
+- get in touch with a provider out of band
+- add obligation to provider
+- remove obligation from provider
+- quickly determine if a new accepted provider is correctly configured
+
+---
+
+#### 2. Apollo
+
+##### As a prospective provider I want to
+- start Apollo with given keys
+- stop Apollo
+- see Apollo session status of node
+- see Apollo recent usage log
+
+---
+
+#### 3. Colossus
+
+##### As a node operator I should be able to:
+- (Stake) Configure and enter storage role entirely from the command line, in an interactive process, where only essential secret keys are required on the node running the storage node software.
+- (Unstake) leave the role easily without loosing access to staked (stash) keys
+- Re-enter the role after unstaking without overwriting old staking keys
+- Get status of my node:
+ - Sync status, IPNS publishing status. Total storage consumed...
+- Get usage stats:
+ - number of objects served/uploaded, total data transferred
+- Check if there is a version update available
+- Enter a test mode - non operational mode for testing setup and configuration
+- Configure a remote IPFS node to use
+- Configure a remote endpoint as joystream full node
+- Gracefully shutdown node
+
+##### The node itself should:
+- Not enter operational status until chain is fully synced
+- Synchronize data objects over IPFS from other storage providers
+- Provide a REST API for receiving new data objects from publishers, and accepting transfers to distributors nodes
+- Provide a REST API for service resolution
+
+---
+
+#### 4. Content Directory
+
+These stories describe functionality of a general purpose Versioned Object Database system upon which the content directory for the platform will be constructed.
+
+##### As system sudo I can:
+- create a new `class group` x1
+- assign a `class group` sudo
+- have same permissions as class group sudo
+
+##### As `class group` sudo I can:
+- create a new Class
+- create a new Entity of an existing Class in my group
+- create a new Schema for a Class in my group, supporting use of an Object Property type that can map to a DataObjectID, of a specific DataObjectFamily from the Data Directory
+- create a new object of a specific schema for an existing Entity in my class group.
+- update the object properties of any object in my class group
+
+##### Any user of the platform can:
+- get a list of all classes, and entities
+- for each class get all its entities
+- for each entity get all versions of its object representation
+
+x1 - A `class group` is a logical grouping of Classes. It allows for segmenting the database and assigning different sudo accounts for different groups. A class group sudo can only create new classes and entities, under their group.
+
+Assume Database has following structure:
+Classes: `["Podcast", "PodcastTheme", "Episode", "Person"]`
+Schemas:
+```
+Podcast {
+ name: varchar(30),
+ host: Internal(Person),
+ // themes: Array(PodcastTheme) // array propertytype is not yet in spec
+ theme: PodcastCategory // might be limiting if a show fits in multiple categories
+}
+
+PodcastTheme {
+ name: varchar(30),
+}
+
+Person {
+ memberId: Option,
+ email: varchar(150),
+}
+
+Episode {
+ podcast: Internal(Podcast),
+ title: varchar(50),
+ guest: Internal(Person), // Array ? guests
+ track: External("DataDirectory", DataObjectFamilyId = 0)
+}
+```
+
+##### In Pioneer a user should be able to:
+- browse list of `Podcast`s,
+- Sort podcasts by `Theme` or show host,
+- select a podcast and get a list of all `Episode`s
+- find episodes (from different shows) on which a guest appeared
+
+Should have similar stories for a `Movie` and associated classes. (Final list of content types to include in Rome is TBD)
+
+##### Stretch Goal
+- In Pioneer, anyone can use a tool to create a *simple text formatted* description of a schema.
+- Sudo can use a command line tool to build an extrinsic that can create a new schema for a class.
+
+Instead of Arrays (eg. to add all guests that appeared on a show), we can have create a Class:
+```
+PodcastGuestAppearance {
+ episode: Internal(Episode),
+ guest: Internal(Person)
+}
+```
+
+---
+
+
+#### 5. Community Fund Proposal System
+
+##### As a platform member and stakeholder, I want
+- a community fund of real money.
+- to be able to make proposals and apply for grants.
+- to be able to propose competitions, and get paid to arrange them.
+- to be able to participate in competitions and win real money.
+- to be able to propose increasing participation payouts.
+- a forum category to discuss and evaluate proposals.
+- insight on what Council Members thinks about proposals.
+
+##### As a Council Member candidate, I want
+- to communicate to stakeholders how I would allocate the resources as part of my campaign.
+- show my constituency that I want to support their cause as part of my campaign.
+- show that I can make good proposals that would help build the community.
+- show that I can evaluate, improve and find flaws in other proposals.
+
+##### As a Council Member, I want
+- all of the above.
+- the ability to vote and allocate the funds.
+
+---
+
+### Minutes
+**Started at:** `11:00 GMT+2`
+**Present:**
+ - `Alex`
+ - `Bedeho`
+ - `Martin`
+ - `Mokhtar`
+
+**Note** All comments are in *italic*
+
+---
+
+#### Item 1
+
+NB1: provider refers to either storage provider or distributor.
+
+NB2: These stories are kind of hand wavy. Many of the stories may be better suited off chain, e.g. coordinated through a server run by conductor. But it remains to be seen.
+
+##### As a prospective provider I want to
+- see terms associated with existing providers roles
+- see terms associated with open positions for new roles
+- apply to an open position with one click
+- leave a role
+
+*It was decided to make the general `actor/working group` signup module small and generic. As a consequence, a lot of this will be off-chain. It was not resolved how much of this was going to be in Pioneer, and how to represent it.*
+
+
+##### As a Conductor I want to
+- add an open position with given terms
+- close an open position
+- slash a provider from a position *(without evicting, ie. only slash part of their stake)*
+- evict a provider from a position
+- add obligation to provider *(content)*
+- remove obligation from provider *(content)*
+- quickly determine if a new accepted provider is correctly configured
+
+*As above: It was decided to make the general `actor/working group` signup module small and generic. As a consequence, a lot of this will be off-chain. It was not resolved how much of this was going to be in Pioneer, and how to represent it.*
+
+
+##### Nice to haves
+- one click download each auto generated key (stash, controller, session) for each role applied to
+- get notified if accepted into a position *(email in node config was considered, or just wait for the chat system)*
+- see list of all positions I have occupied now and prior, and corresponding payouts, and circumstances of leaving.
+- get notified if slashed *(email in node config was considered, or just wait for the chat system)*
+- get notified if evicted *(email in node config was considered, or just wait for the chat system)*
+- get in touch with a provider out of band *(email in node config was considered, or just wait for the chat system)*
+
+*These stories were removed from the the "must haves" to "nice to haves"*
+
+---
+
+#### Item 2
+
+##### As a prospective provider I want to
+- start Apollo with given keys *(ie. use a session key, similar to running a joystream full node)*
+- stop Apollo
+- see Apollo session status of node *(similar to what "helios" already does)*
+- see Apollo recent usage log *(This is/will be possible using the setup guide in helpdesk)*
+
+---
+
+#### Item 3
+
+##### As a node operator I should be able to:
+- Get status of my node:
+ - Sync status, IPNS publishing status. *("Total storage consumed..." was moved to nice to have)*
+- Configure a remote IPFS node to use
+
+##### The node itself should:
+- Not enter operational status until chain is fully synced *(This refers to the joystream-node)*
+- Synchronize data objects over IPFS from other storage providers
+- Provide a REST API for receiving new data objects from publishers, and accepting transfers to distributors nodes
+- Provide a REST API for service resolution
+
+*The final three points are already existing functionality*
+
+##### Nice to haves
+- Check if there is a version update available
+- Get usage stats:
+ - number of objects served/uploaded, total data transferred
+- Enter a test mode - non operational mode for testing setup and configuration *x*
+- Configure a remote endpoint as joystream full node *x*
+*x these two combined would mean users could test on a "reckless" testnet*
+- Gracefully shutdown node *(Refers to announcing you are down for maintenance)*
+- Get status of my node:
+ - Total storage consumed...
+
+*These stories were removed from the the "must haves" to "nice to haves"*
+
+---
+
+This was as far as we got on the first meeting. The remaining items will be addressed at a later date.
+
+**Other topics raised:**
+
+While going through items 1-3, a recurring topic was how much time and effort should be put into making the products user friendly, compared to the "quantity" and "quality" of users affected.
+
+More specifically, should we optimize to make it easy for actors, that are well paid for a role, without actually risking anything (no "real" stake), or should we rather expect them to monitor communication channels and the status of their software. By making everything easily accessible in Pioneer, and adding new ways of communicating directly, we are adding a significant workload on ourselves.
+
+**Ended at:** `12:30 GMT+2`
+
+---
+
+**Day two:**
+**Started at:** `17.07.19 - 09:00 GMT+2`
+**Present:**
+ - `Alex`
+ - `Bedeho`
+ - `Martin`
+ - `Mokhtar`
+
+---
+
+#### Item 4
+
+These stories describe functionality of a general purpose Versioned Object Database system upon which the content directory for the platform will be constructed.
+
+##### As system sudo I can:
+- create a new `content directory sudo`
+- assign a `content directory sudo`
+
+ *implement group permission in a separate module*
+
+##### As `content directory sudo` I can:
+- create a new Class
+- create a new Entity of an existing Class in my group
+- create a new Schema for a Class, supporting use of an Object Property type that can map to a DataObjectID, of a specific DataObjectFamily from the Data Directory
+- create a new object of a specific schema for an existing Entity
+- update the object properties of any object
+- use a command line tool or the extrinsics app from pioneer to send a tx and create a new schema for a class.
+
+*The final point was moved from nice to haves, as there has to be some way of making these. Whether the first implementation should be done via, extrinsics in pioneer or a standalone CLI, is TBD*
+
+##### Any user of the platform can use Pioneer to:
+- get a list of all classes, and entities
+- for each class get all its entities
+- for each entity get all versions of its object representation
+
+*It was not settled whether this should be via "regular" chain state queries, or a new x*
+
+##### As an uploader I can:
+- create a subset of Entities and Objects which the permissions module will limit to Members
+- update a subset of Entities and Objects which permissions module will limit to content owner
+
+*Added so that uploaders can actually add metadata (such as "title" and "description" without extra permissions)*
+
+Assume Database has following structure:
+Classes: `["Podcast", "PodcastTheme", "Episode", "Person"]`
+Schemas:
+```
+Podcast {
+ name: varchar(30),
+ host: Internal(Person),
+ // themes: Array(PodcastTheme) // array propertytype is not yet in spec
+ theme: PodcastCategory // might be limiting if a show fits in multiple categories
+}
+
+PodcastTheme {
+ name: varchar(30),
+}
+
+Person {
+ memberId: Option,
+ email: varchar(150),
+}
+
+Episode {
+ podcast: Internal(Podcast),
+ title: varchar(50),
+ guest: Internal(Person), // Array ? guests
+ track: External("DataDirectory", DataObjectFamilyId = 0)
+}
+```
+
+##### In Pioneer a user should be able to:
+- browse list of `Podcast`s, *(example)*
+- Sort podcasts by `Theme` or show host,
+- select a podcast and get a list of all `Episode`s
+- find episodes (from different shows) on which a guest appeared
+
+Should have similar stories for a `Movie` and associated classes. (Final list of content types to include in Rome is TBD)
+
+*The representation of this in pioneer is very much a WIP still*
+
+---
+
+#### Item 5
+
+Not addressed yet.
+
+---
+
+
+**Ended at:** `11:15 GMT+2`
+
+---
+
+## Release Plan Finalization Meeting
+
+- **ID:** `Rome Release Plan Finalization Meeting`
+- **Date:** `20.08.19`
+- **Starts:** `11:15 GMT+2`
+- **Scheduled Duration:** `90min`
+- **Venue:** `ZOOM`
+- **Lead**: `Martin`
+- **Minutes**: `Martin`
+- **Participants**:
+ - `Alex`
+ - `Bedeho`
+ - `Martin`
+ - `Mokhtar`
+ - `Paul`
+
+### Agenda
+#### Item 1
+Go through the draft Release Plan and OKRs.
+- Correct any errors
+- Resolve open questions
+- Ensure the process is clear to all
+- Revisit the *very tentative* milestone dates
+
+#### Item 2
+Go through the Tracking Issues
+- Discuss how they are split
+- Discuss granularity
+- Discuss assigning
+- Discuss Tracking Issues -> OKR grading
+
+### Minutes
+**Started at:** `11:15 GMT+2`
+**Present:**
+ - `All`
+
+#### Item 1
+
+Started with a brief introduction of the new Release Plan format.
+
+- The main topic of discussion was the OKRs.
+ - Some changes were requested for clarity.
+ - Some numbers were changed for the community engagement KRs.
+- We agreed to leave the Milestone dates as proposed for now.
+- We agreed to upgrade the Substrate Node Template to a newer version, but decided to await more research and testing before choosing a specific version.
+- We agreed not to migrate any content from Acropolis to Rome.
+
+#### Item 2
+
+Started with a brief introduction of the Tracking Issues.
+
+- Two main issues raised:
+ - Should we add tentative dates to all tasks?
+ - We decided not to for now.
+ - Not everyone was convinced the Tracking Issues was split correctly.
+ - We decided to leave them as is unless a detailed counter proposal was made.
+- Due to time constraints, we only looked at their structure.
+- Everyone is responsible for reviewing the Tracking Issues, and propose improvements and additions.
+- Some good suggestions, like adding testing, was proposed and will be implemented.
+
+
+**Other topics raised:**
+
+NA
+
+**Ended at:** `12:50 GMT+2`
diff --git a/meetings/rome/img/meetings-cover.svg b/meetings/rome/img/meetings-cover.svg
new file mode 100644
index 0000000000..a8b64cad12
--- /dev/null
+++ b/meetings/rome/img/meetings-cover.svg
@@ -0,0 +1,215 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/okrs/README.md b/okrs/README.md
index c10b25e4d0..50b94e60a9 100644
--- a/okrs/README.md
+++ b/okrs/README.md
@@ -7,19 +7,20 @@
The line between bureaucracy and rigour is 1px thin, but what are we to do? :pray:
-# Table of contents
+Table of Contents
+=================
+
- [Archive](#archive)
- [Project OKRs](#project-okrs)
- - [Launch Joystream on mainnet](#wip-construction_worker-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`](#wip-construction_worker-objective-launch-a-functional-upgradable-video-platform-governed-and-operated-by-a-vibrant-community)
- [Quarterly OKRs](#quarterly-okrs)
- - [Increase the Joystream building power](#objective-increase-the-joystream-building-power)
- - [Expand Joystream brand awareness](#objective-expand-joystream-brand-awareness)
- [Release OKRs](#release-okrs)
- - [Launch Acropolis network](#objective-launch-acropolis-network)
+ - [Objective: `Introduce a Better Content System`](#objective-introduce-a-better-content-system)
+ - [Objective: `Engage community to understand Rome and join us in the future`](#objective-engage-community-to-understand-rome-and-join-us-in-the-future)
+- [Group OKRs](#group-okrs)
- [Personal OKRs](#personal-okrs)
- - [Bedeho - Improve Technical Productivity of Team](#objective-improve-technical-productivity-of-team)
- - [Martin - Improve value as Release Manager](#objective-improve-value-as-release-manager)
+
# Archive
@@ -56,61 +57,88 @@ TBD
# Release OKRs
-## Objective: `Launch Acropolis Network`
-- **Active from:** 09.05.19
-- **KR Measurement Deadline**: 7-9 days after Acropolis launch (first weekday)
-- **Tracked**: Every Monday
+## Objective: `Introduce a Better Content System`
+- **Active from:** 20.08.19
+- **KR Measurement Deadline**: 7 days after Rome launch
+- **Tracked**: Every Tuesday
- **Tracking Manager**: Martin
- **Key Results**:
-1. `Get 75 posts on forum (limits, not Jsg) (ewd)`
- - Bedeho: 2/3
- - Alex: 1/3
-2. `Forum (runtime), storage (runtime and P2P) fully specd (n)`
- - Bedeho (as manager): 1/2
- - Bedeho (as writer): 1/6
- - Jens: 2/6
- - Mokhtar from 10.06.19
-3. `Have 4x replication for all 2 tranches on storage node (ewd)`
- - Jens: 2/3
- - Mokhtar from 10.06.19
- - Mokhtar: 1/3
-4. `95% uptime Storage Providers (ewd)`
- - Jens: 1/4
- - 0 from 10.06.19
- - Mokhtar: 1/4
- - 1/2 from 10.06.19
- - Martin: 1/4
- - Alex: 1/4
-5. `No PRs merged to master (excluding bugfixes and "pioneer") after "Sub-system Test" (conf)`
- - Martin: 1/2
- - Jens: 1/8
- - 0 from 10.06.19
- - Mokhtar: 1/8
- - 1/6 from 10.06.19
- - Bedeho: 1/8
- - 1/6 from 10.06.19
- - Alex: 1/8
- - 1/6 from 10.06.19
+ 1. `Members can make a Content Creator profile and publish content under this profile.`
+ 2. `Introduce the role of staked Content Curators, policed by sudo.`
+
+ 3. `Launch with 3 content types.`
+
+ 4. `Add 1 new content type after release.`
+
+ 5. `Add a new schema for a content type, and migrate only some instances to the new schema.`
-- **Notes**
- * During the first tracking, it was decided to track KR5 by how confident (conf) each assigned individual is that the KR will be achieved.
-# Table of contents
+Table of Contents
+=================
+
- [Overview](#overview)
- [Testnet Releases](#testnet-releases)
- - [Live Testnet](#live-testnet)
- - [Next Testnet](#next-testnet)
- - [Past Testnets](#past-testnets)
+ - [Live Testnet](#live-testnet)
+ - [Next Testnet](#next-testnet)
+ - [Past Testnets](#past-testnets)
- [Templates](#templates)
+
# Overview
@@ -18,17 +21,20 @@ It also contains templates for for planning releases.
## Live Testnet
-[Athens](testnets/athens/README.md)
+[Acropolis](acropolis)
## Next Testnet
-[Acropolis](testnets/acropolis/README.md)
+[Rome](rome)
+
## Past Testnets
| Network | Started | Ended | Release Plan |
| ------------- | ------------- | ----- | ----- |
+| Athens | 27.04.19 | 24.06.19 | [Link](athens) |
| Sparta | 28.02.19 | 29.03.19 | NA |
| Mesopotamia | 21.12.18 | 28.02.19 | NA |
+
# Templates
diff --git a/testnets/branding-template.md b/testnets/branding-template.md
deleted file mode 100644
index ad3f9f6219..0000000000
--- a/testnets/branding-template.md
+++ /dev/null
@@ -1,25 +0,0 @@
-# Table of contents
-
-- [Name](#name)
-- [Naming Rational](#naming-rational)
-- [Goals](#goals)
- - [Technical](#technical)
- - [Community](#community)
-- [Logomark](#logomark)
-
-# Name
-``
-
-# Naming Rational
-
-
-# Goals
-The major of goals of the `` testnet is the following:
-
-## Technical
-
-
-## Community
-
-
-# Logomark
diff --git a/testnets/rome/README.md b/testnets/rome/README.md
new file mode 100644
index 0000000000..4391a4db51
--- /dev/null
+++ b/testnets/rome/README.md
@@ -0,0 +1,176 @@
+
diff --git a/testnets/rome/branding/img/rome-logomark.png b/testnets/rome/branding/img/rome-logomark.png
new file mode 100644
index 0000000000..6e014d1c6e
Binary files /dev/null and b/testnets/rome/branding/img/rome-logomark.png differ
diff --git a/testnets/rome/img/rome-cover.svg b/testnets/rome/img/rome-cover.svg
new file mode 100644
index 0000000000..e0c5fc166c
--- /dev/null
+++ b/testnets/rome/img/rome-cover.svg
@@ -0,0 +1 @@
+Artboard 7 copy 2 
-## Why is this on Github?
+## Why is this on GitHub?
-The reason this is placed in public view on Github is 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.
+- **Open Invitation:** Serves 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.
+- **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.