Updated README.md's for Rome

README.md

@@ -14,8 +14,8 @@
 
 <div align="center">
   <h3>
-    <a href="/testnets/acropolis">
-      Acropolis Testnet
+    <a href="/testnets/rome">
+      Rome Testnet
     </a>
     <span> | </span>
     <a href="/okrs">
@@ -30,9 +30,6 @@
       Helpdesk
     </a>
     <span> | </span>
-    <a href="/testnets/rome">
-      Rome Testnet
-    </a>
   </h3>
 </div>
 
@@ -73,14 +70,14 @@ Table of Contents
 
 # Overview
 
-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.
+This landing repo is intended to be the best starting place to get a coherent view of how information is organized in this GitHub organization.
 
 # Contribute
 
 For software development we try to follow the [git-flow](https://nvie.com/posts/a-successful-git-branching-model/) branching [model](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow) with some minor differences:
   - `development` branch instead of `develop`.
   - feature branches should be created in contributors' own fork of the repo.
-  - for more collaborative long running feature development, a feature branch may be created by the maintainer on the central repo.
+  - for more collaborative long-running feature development, a feature branch may be created by the maintainer on the central repo.
 
 The central repos will have multiple members of the core team with write access, but there will be one designated maintainer or "product owner" and responsible for the final product. The maintainer must approve either directly or by delegation (accepting other members' reviews) PRs to be merged.
 
@@ -90,7 +87,7 @@ The core team, maintainers and outside contributors are encouraged to follow the
 * 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 be merged once CI checks are complete.
+* Authors must always request a review for their PRs, Exception: It does not alter any logic (e.g. comments, dependencies, docs, file organization), then it may be merged once CI checks are complete.
 * Author should avoid merging their own PR, if it hasn't been reviewed and approved.
 * If travis or other CI integrations are configured for the repo, avoid merging PRs that fail checks.
 * When the maintainer is opening a PRs they must still request a review from a core team member.
@@ -98,7 +95,7 @@ The core team, maintainers and outside contributors are encouraged to follow the
 Each repository may have contributing guidelines detailed in their README files.
 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
 
@@ -125,6 +122,7 @@ This is the set of active repos to which this document refers:
 | [bounties](https://github.com/Joystream/bounties)                             | Bounties and testnet payout overview.    | @blrhc           |
 | [design](https://github.com/Joystream/design)                             | Joystream brand guide and assets.    | @bwhm           |
 | [manifesto](https://github.com/Joystream/manifesto)                             | The Joystream manifesto.    | @bedeho           |
+| [joystream-content-system](https://github.com/Joystream/joystream-content-system)                             | A repo containing information and resources about the Joystream content system.     | @bwhm           |
 
 ## Runtime Repos
 
@@ -157,11 +155,11 @@ Until the Joystream mainnet goes live, a sequence of test networks will be rolle
 
 ## Live Testnet
 
-[Acropolis](/testnets/acropolis/README.md)
+[Rome](/testnets/rome/README.md)
 
 ## Next Testnet
 
-[Rome](testnets/rome)
+Constantinople
 
 
 ## Past Testnets
@@ -171,6 +169,7 @@ Until the Joystream mainnet goes live, a sequence of test networks will be rolle
 | Athens          | 17.04.19          |   24.06.19    | [Link](/testnets/athens/README.md)        |
 | Sparta          | 28.02.19          |   29.03.19    |       N/A        |
 | Mesopotamia     | 21.12.18          |   28.02.19    |       N/A        |
+| Acropolis       | 24.06.19          |   13.03.20    | [Link](/testnets/acropolis/README.md)        |
 
 <br />
 <img src="img/pm-section_new.svg" id="project-management"/>
@@ -198,7 +197,7 @@ Meeting itineraries are prepared on a case by case basis, depending on the conte
 - **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 Telegram for invite).
+- **Participant:** Core Jsgenesis team _must_ be present, anyone else is welcome (join Telegram for invite).
 - **Record&Publish:** YES, if no participant objects.
 
 #### Tuesday all-hands
@@ -210,7 +209,7 @@ Meeting itineraries are prepared on a case by case basis, depending on the conte
   4. **Announcements:** Anything you think should be brought to everyone's attention.
 - **When:** Every working Tuesday at 10am (GMT)
 - **Where:** Zoom
-- **Participant:** Core Jsgenesis team _must_ be present, any one else is welcome (join Telegram for invite).
+- **Participant:** Core Jsgenesis team _must_ be present, anyone else is welcome (join Telegram for invite).
 - **Record&Publish:** YES, if no participant objects.
 
 #### Release meeting
@@ -218,17 +217,17 @@ Meeting itineraries are prepared on a case by case basis, depending on the conte
 - **Description:** Discussion concerning testnet planning and release.
 - **When:** On-demand
 - **Where:** Zoom
-- **Participant:** Core release team _must_ be present, any one else is welcome (join Telegram for invite).
+- **Participant:** Core release team _must_ be present, anyone else is welcome (join Telegram for invite).
 - **Record&Publish:** YES, if no participant objects.
 
 <br />
 <img src="img/okr-section_new.svg" id="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).
+Project management is primarily centered 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 constitutes 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.
+A key result can be _assigned_ to a mix of people or other objectives. The _assignment set_ of a key result constitutes 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
 
@@ -242,7 +241,7 @@ The OKRs can be classified into two separate families of types, first:
 
 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).
+- **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 rationalized 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 group OKRs, only applying to a single person only. The current set of such OKRs can be found [below](#personal-okrs).
 
@@ -258,17 +257,17 @@ The following figure attempts to summarise how these OKR families and types are
 
 ### 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.
+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.
+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 its forecasted value, do as indicated in the example figure below.
 
 ![alt text](img/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 (n)**: 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.
+- **Naive (n)**: 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.
 
 - **Estimate of Work Done (ewd)**: 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.
 
@@ -282,8 +281,8 @@ The template used for recording and tracking OKRs has the following form:
  - **Active from:** `<When the OKR is set/live>`
  - **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>`
+ - **Tracking Manager**: `<Name of person responsible for doing tracking, at a given interval, and final grading>`
+ - **Key Results**: `<If all key results have the same assignment set, write here>`
    1. `<Statement of Key result>` `<n/ewd>`
      - `<Name of assignee>`: `<assignment weight>`
      - ...
@@ -340,17 +339,17 @@ Each release is directed by a _Release Manager_ (**RM**) who is responsible for:
 
 ### Tracking Issues
 
-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 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.
+A Tracking Issue is a GitHub issue which **evolves**, and at any given time holds a list of TODO items, with corresponding completion status 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.
 
 - 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.
+- 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.
 
 ### Milestones
 
-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:
+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 has 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

meetings/README.md

@@ -21,7 +21,7 @@ Table of Contents
 
 # Meeting Archiving
 
-Each meeting which will be archived has a _meeting identifier_, which should reflect the topics covered, as seen in the template [below](#meeting-itinerary-archive-index). The itinerary, and any other related assets, for a meeting should be placed in a subdirectory of this directory with the same name as this identifier.
+Each meeting that will be archived has a _meeting identifier_, which should reflect the topics covered, as seen in the template [below](#meeting-itinerary-archive-index). The itinerary, and any other related assets, for a meeting, should be placed in a subdirectory of this directory with the same name as this identifier.
 
 # Archive Index
 

meetings/rome/README.md

@@ -44,8 +44,8 @@ Table of Contents
 
 ### 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.
+1. Review the [Release Checklist](../../testnet#release-checklist) draft, and compare it to the release plan.
+2. Land a final Release Checklist, that contains all items and sorted it in order of deployment.
 
 
 ### Minutes
@@ -134,7 +134,7 @@ Schedule [user stories meeting](#user-stories-meeting)
 
 #### 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.
+2. Points that were unclear, inaccurate, missing or wrong, were 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).
@@ -143,7 +143,7 @@ Schedule [user stories meeting](#user-stories-meeting)
     - 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.
+    - A summary of that weeks meeting, alongside a tracking grade, would be added as a 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.
@@ -209,8 +209,8 @@ NB2: These stories are kind of hand wavy. Many of the stories may be better suit
 - 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
+- add an obligation to the provider
+- remove the obligation from provider
 - quickly determine if a new accepted provider is correctly configured
 
 ---
@@ -229,20 +229,20 @@ NB2: These stories are kind of hand wavy. Many of the stories may be better suit
 
 ##### 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
+- (Unstake) leave the role easily without losing 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
+- 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
+- Not enter operational status until the 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
@@ -251,7 +251,7 @@ NB2: These stories are kind of hand wavy. Many of the stories may be better suit
 
 #### 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.
+These stories describe the 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
@@ -360,7 +360,7 @@ PodcastGuestAppearance {
 
 #### Item 1
 
-NB1: provider refers to either storage provider or distributor.
+NB1: provider refers to either a 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.
 
@@ -378,8 +378,8 @@ NB2: These stories are kind of hand wavy. Many of the stories may be better suit
 - 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)*
+- add an obligation to provider *(content)*
+- remove the 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.*
@@ -426,7 +426,7 @@ NB2: These stories are kind of hand wavy. Many of the stories may be better suit
 - 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*
+- 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)*
@@ -461,7 +461,7 @@ More specifically, should we optimize to make it easy for actors, that are well
 
 #### 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.
+These stories describe the 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`
@@ -488,7 +488,7 @@ These stories describe functionality of a general purpose Versioned Object Datab
 
 ##### 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
+- update a subset of Entities and Objects which permissions module will limit to the content owner
 
 *Added so that uploaders can actually add metadata (such as "title" and "description" without extra permissions)*
 
@@ -597,7 +597,7 @@ 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.
+  - Not everyone was convinced the Tracking Issues were 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.
@@ -647,7 +647,7 @@ We kept quite strictly to the schedule laid out [here](sprint-in-london.md) for
 - There was a lot of value in lots of the work conducted in smaller groups and one-on-one.
 - Cross-communication was also very useful and was enabled by the physical nature of the meeting.
 - Smaller gatherings are often better than larger ones (i.e. sprint) for productivity.
-- Time spent programming etc. was occasionally not best deployment of time. Some team members felt that we should have exclusively focussed team and pair activities made much easier by "being in a room together"
+- Time spent programming etc. was occasionally not the best deployment of time. Some team members felt that we should have exclusively focussed team and pair activities made much easier by "being in a room together"
 - Whiteboard time was very useful and could not be easily replicated using video conference etc.
 - Some wondered whether the trip was cost-effective.
 - Some felt that the itinerary could have been better organized e.g. mealtimes.
@@ -656,7 +656,7 @@ We kept quite strictly to the schedule laid out [here](sprint-in-london.md) for
 - We should have avoided excessive focus on tracking progress, no fun, adds little value.
 - We should have had daily "standup" at a specific time to help efficiently starting collaboration each day.
 - Best time for a sprint is perhaps super early in a release, or with more RnD/experimental focus, rather than tied to shipping.
-- We didn't always stick to schedule.
+- We didn't always stick to the schedule.
 - It was very good for morale for everyone to meet each other.
 - Some of the early meetings involved people who were not relevant to the topics discussed, wasting time.
 
@@ -795,7 +795,7 @@ We kept quite strictly to the schedule laid out [here](sprint-in-london.md) for
 1. In terms of `schemas`, we still need to implement channel as a property of a video (`channel-id`).
 2. Alex needs 1-2 more days of work on channel creation/editing for Pioneer.
 3. Channel curation and moderation does not need to be implemented in Pioneer. The ability to delete channels through `sudo` will be added post Rome release.
-4. Content creation and editing in Pioneer needs 3 more days of work by Alex. The UI and styling is already complete.
+4. Content creation and editing in Pioneer needs 3 more days of work by Alex. The UI and styling are already complete.
 5. Content consumption and exploration on Pioneer will need about half a day more work. We will not be including pagination on launch.
 
 
@@ -816,7 +816,7 @@ We kept quite strictly to the schedule laid out [here](sprint-in-london.md) for
 2. We won't be implementing support for "cleaning" content from storage nodes until after release.
 3. Mokhtar has finished migration.
 4. We also agreed that Aracus should be killed and replaced with some new Joystream-hosted nodes. Provisionally we agreed that these might be made up of 2 bootnodes, 1 also performing media discovery, 1 also acting as our storage provider and 1 or more nodes hosting Pioneer, with load balancing if applicable.
-5. The following `genesis config paramaters` need to be re-evaluated:
+5. The following `genesis config parameters` need to be re-evaluated:
 - Balances for existing members
 - Payouts (JOY) for Storage Providers, Validators and Curators
 - Open slots for Storage Providers, Validators and Curators

okrs/README.md

@@ -99,7 +99,7 @@ TBD
 
 <br />
 
-## Objective: `Engage community to understand Rome and join us in the future`
+## Objective: `Engage the community to understand Rome and join us in the future`
 - **Active from:** 20.08.19
 - **KR Measurement Deadline**: 7 days after Rome launch
 - **Tracked**: Every Tuesday
@@ -154,7 +154,7 @@ TBD
 
 * [Community OKR](#objective-engage-community-to-understand-rome-and-join-us-in-the-future)
   * `2.` "Active" means Content Curators that are not fired as a result of not following their responsibilities.
-  * `3. & 4.`: Content "items" means number of entries in the content directory, not the data objects associated with the entry.
+  * `3. & 4.`: Content "items" means a number of entries in the content directory, not the data objects associated with the entry.
 
 See [Release Plan](/testnets/rome/README.md#general) for general notes on the Release OKRs.
 

reports/README.md

@@ -8,7 +8,7 @@
 
 # Reports
 
-Reports are documents describing the discussion and decision making that results from meetings which were not scheduled to have note taking, yet ended up being very significant in technical or organisational respects.
+Reports are documents describing the discussion and decision making that results from meetings which were not scheduled to have note taking, yet ended up being very significant in technical or organizational respects.
 
 # Format
 

testnets/README.md

@@ -21,11 +21,11 @@ It also contains templates for planning releases.
 
 ## Live Testnet
 
-[Acropolis](acropolis)
+[Rome](rome)
 
 ## Next Testnet
 
-[Rome](rome)
+Constantinople
 
 
 ## Past Testnets
@@ -35,6 +35,7 @@ It also contains templates for planning releases.
 | 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        |
+| Acropolis       | 24.06.19          |   13.03.20    | [Link](acropolis)        |
 
 
 # Templates

testnets/rome/README.md

@@ -30,9 +30,9 @@ Table of Contents
 
 During the planning stages of a new testnet, we produce a new release plan.
 
-While working on [Acropolis](/testnets/acropolis), we decided to abandon the approach of creating a single `Release Project` kanban board on GitHub. These quickly became bloated, and created more confusion than value. We instead created [Tracking Issues](#tracking-issues) for the two major component of the release - the [forum](https://github.com/Joystream/joystream/issues/47) and the [storage node](https://github.com/Joystream/joystream/issues/57). These made it far simpler to get a good grasp of completed and outstanding items at a high level.
+While working on [Acropolis](/testnets/acropolis), we decided to abandon the approach of creating a single `Release Project` kanban board on GitHub. These quickly became bloated and created more confusion than value. We instead created [Tracking Issues](#tracking-issues) for the two major component of the release - the [forum](https://github.com/Joystream/joystream/issues/47) and the [storage node](https://github.com/Joystream/joystream/issues/57). These made it far simpler to get a good grasp of completed and outstanding items at a high level.
 
-After the [Acropolis Lessons Learned Meeting](/meetings/acropolis#lessons-learned), and thinking about our approach to project management and progress tracking, we have decided to expand on this concept. The release plan will no longer contain a "todo" list, but instead link to "live" [Tracking Issues](#tracking-issues) covering all aspects and actions of the release. Each of these will be as contained as they can, to avoid the need for all team members to be present and listening to in-depth technical and organizational conversations outside of their scope.
+After the [Acropolis Lessons Learned Meeting](/meetings/acropolis#lessons-learned), and thinking about our approach to project management and progress tracking, we have decided to expand on this concept. The release plan will no longer contain a "todo" list but instead link to "live" [Tracking Issues](#tracking-issues) covering all aspects and actions of the release. Each of these will be as contained as they can, to avoid the need for all team members to be present and listening to in-depth technical and organizational conversations outside of their scope.
 
 #  Specification
 
@@ -79,7 +79,7 @@ This Release Plan is considered "final" once merged to master, and anything belo
 <br />
 
 
-### Objective: `Engage community to understand Rome and join us in the future`
+### Objective: `Engage the community to understand Rome and join us in the future`
 - **Active from:** 20.08.19
 - **KR Measurement Deadline**: 7 days after Rome launch
 - **Tracked**: Every Tuesday
@@ -105,10 +105,10 @@ This Release Plan is considered "final" once merged to master, and anything belo
 
 * [Community OKR](#objective-engage-community-to-understand-rome-and-join-us-in-the-future)
   * `2.` "Active" means Content Curators that are not fired as a result of not following their responsibilities.
-  * `3. & 4.`: Content "items" means number of entries in the content directory, not the data objects associated with the entry.
+  * `3. & 4.`: Content "items" means the number of entries in the content directory, not the data objects associated with the entry.
 
 ##### General
-* For previous testnet, we have tried making each KR be a mix of pure technical implementation, and community engagement in one single release OKR. This lead to:
+* For the previous testnet, we have tried making each KR be a mix of pure technical implementation, and community engagement in one single release OKR. This lead to:
   * confusion during tracking
   * unclear responsibilities and primary focus (ie. make it work, or make it user friendly)
   * ambiguity around time and deadlines