[meta] add editing quick start helper (#96)

* local images

* fix links

* add quick start doc

* try to remove previews on every PR sync

* update preview ci version

* remove build folder

* remove build

* trigger preview

* clean

.github/workflows/preview.yml

@@ -24,13 +24,14 @@ jobs:
       - uses: oven-sh/setup-bun@v2
       # this has to match docusaurus's baseURL in docusaurus.config.js
       - run: echo "GH_ACTION_DOCUSAURUS_BASE_URL=pr-preview/pr-${{ github.event.number }}" >> "$GITHUB_ENV"
+
       - name: Install and Build
         if: github.event.action != 'closed' # You might want to skip the build if the PR has been closed
         run: |
           bun install --frozen-lockfile
           bun run build
 
       - name: Deploy preview
-        uses: rossjrw/pr-preview-action@v1
+        uses: rossjrw/pr-preview-action@v1.4.7
         with:
           source-dir: ./build

docs/archive/community/governance.todo

@@ -29,7 +29,7 @@ In January of 2022, the community adopted a proposal to implement MVP community
 
 
 
-![](http://openlibra.blog/wp-content/uploads/2022/05/WG-Org-Chart.png)
+![](../../assets/wg-org-chart-example.png)
 
 
 
@@ -50,5 +50,3 @@ While the working group process has been functional for coordination of tasks an
 
 
 On 3 May 2022, the community voted to adopt the 0L Network Constitution, which lays out the Community’s foundational values. The creation of the Constitution was a major step towards establishing a decision framework and value system that can serve as the project’s north star as we move forward. You can [read the Constitution here.](http://openlibra.blog/community/governance/the-0l-network-constitution/)
-
-

docs/archive/proposals/October_2022_Governance_Recap.md

@@ -1,3 +1,4 @@
+# October 2022 Governance Recap
 
 The 0L Community recently concluded its first round of collaborative, decentralized strategic planning. Starting first with rounds of guided discussion on the [RadicalxChange Voice](https://voice.radicalxchange.org/) platform, the process culminated with a set of eight proposals for community vote. In this blog post, we’re going to take a brief look at the contents of those proposals and reflect on the outcomes of the vote. 
 
@@ -219,5 +220,3 @@ Stepping back a moment and looking at the sum of the proposals on the slate:
 
 
 At the end of all this, the answer to the question “where do we go from here?” depends on whether the individual members of our community can move forward with collaborative action. The successful completion of this community strategy development process, while meaningful, is all for naught if the community does not step up and commit the resources needed to operationalize the strategy.
-
-

docs/archive/proposals/Team_Arctika_Recommendation.md

@@ -11,14 +11,17 @@ The crypto headwinds are significant: Regulatory pressure, fraud, scammers and a
 ## How much is necessary for the Infrastructure Escrow Fund (IEF)?
 
 
-We can estimate that, in order to attract validators, the network will have to pay each validator US$4-5k per month (this is consistent with what validators are paid in mature networks with smoothly operating software). In our interviews with professional validators, we arrived at $4,200 as our baseline. See the data in the table, below
-![](http://openlibra.blog/wp-content/uploads/2023/10/Screenshot-2023-10-24-at-15.41.46-1024x558.png)
+We can estimate that, in order to attract validators, the network will have to pay each validator US$4-5k per month (this is consistent with what validators are paid in mature networks with smoothly operating software). In our interviews with professional validators, we arrived at $4,200 as our baseline. See the data in the table, below:
+
+
+![](../../assets/validator-opportunity-cost.png)
 The Team agrees that we need to provision for another 7 years of network operations. We’re roughly three years into the network’s life cycle at this point in time (1 year in testnet, followed by almost 2 years since Genesis). Altogether, we should make it through at least the first 10 years of the network.
 
 
 Of course, translating a token with no market value into monthly USD amounts requires some assumptions about value. We must take a conservative approach on market cap, for "all weather conditions". Despite what we’ve seen with some of our peer networks, we can't reasonably say that the base case for networks is a valuation of $1B\+ over the next 7 years. Likewise a network worth less than $50M for many years likely leads to extinction. So, the calculations we made assumed a $100M market cap, from which a token value could be extrapolated; this seemed like a reasonable base-case (which could be substantiated further).
 At that intersection: 100 validators earning $4,200 per month over 7 years, with a network on average worth $100m, the result is approx 35% of network capital needs to be pre-diluted for sufficient safety.
-![](http://openlibra.blog/wp-content/uploads/2023/10/Screenshot-2023-10-24-at-15.35.30-1024x623.png)
+
+![](../../assets/infrastructure-escrow-pledge-sensitivity.png)
 ### Over-allocation
 
 
@@ -75,7 +78,8 @@ We looked at many models of dilutions and fees. Asking validators to invest 80%
 * Reduce the gap between worker and validators to 1\.3X from 16X.
 
 
-![](http://openlibra.blog/wp-content/uploads/2023/10/Screenshot-2023-10-24-at-15.39.46-1024x750.png)
+![](../../assets/summary-dilution-impacts.png)
+
 We think this allocation, with abundant amounts for future capital, which honors prior workers such that we can continue recruiting for future talent, and sets up all current participants for future success is **unique and exemplary in the industry, and fulfills our mission of creating "good capital" and gives us the best shot at surviving and thriving.**
 
 

docs/community programs/_category_.json

@@ -0,0 +1,8 @@
+{
+    "label": "Programs",
+    "position": 3,
+    "link": {
+      "type": "generated-index",
+      "description": "Third-party programs by community members"
+    }
+}

docs/developers/_category_.json

@@ -1,6 +1,6 @@
 {
     "label": "Developers",
-    "position": 6,
+    "position": 4,
     "link": {
       "type": "generated-index",
       "description": "Information for Developing of the 0L Network"

docs/edit-docs/_category_.json

@@ -0,0 +1,8 @@
+{
+    "label": "Write Docs",
+    "position": 10,
+    "link": {
+      "type": "generated-index",
+      "description": "Tooling information for the 0L Network"
+    }
+}

docs/edit-docs/editing.md

@@ -0,0 +1,82 @@
+---
+# BAD: you should not include a `title` field here, instead you should carefully consider the actual header in the document. Notice in this example it is different than the filename.
+
+# title: "Quick Start"
+
+# GOOD: if I want a different label in the menu rather than my title (e.g. because it's too long)
+# sidebar_label: 'My Title'
+
+# GOOD: if I want to propose an order to the menu
+# sidebar_position: 5
+
+# GOOD: shall we hide this page in the menu?
+# hidden: true
+
+# BAD: if you add a description you'll need to maintain it. Better to not use it.
+# description: 'Shows this on mouseover'
+---
+
+# Editing Documents
+
+## Conventions
+
+### Filenames
+filenames are in "snakecase", lowercase, with underscore for spaces. The file extension should always be `.md`.
+
+Like this:
+ `this_is_a_file.md`
+
+### Metadata
+At the top of an `.md` file you may include some metadata which Docusaurus will be able to read and use for parts of the UX (e.g. titles, is it hidden, menu position).
+
+```
+---
+title: "Menu Title"
+sidebar_label: 'My Title'
+sidebar_position: 5
+hidden: true
+description: 'Shows this on mouseover'
+---
+```
+### Titles
+There are two ways to set the title in docusaurus. Either set it in the metadata, or put a top level section header `# This Title`.
+You should always have a document that begins with a section title.
+
+##### Don't use metadata
+You should not include a `title` field in metadata, instead you should carefully consider the actual header in the document.
+
+### Menu Labels
+The fallback behavior for menu link names will be the filename, e.g.: `this_is_a_file`.
+However if your Doc begins with a header title, e.g.: `# My Article`, then the menu label will be exactly that.
+To override both cases you can include this item to the metadata: `sidebar_label: Actual Label`.
+
+#### Images
+Do not link externally to images. Place copies of images in the `./docs/assets` folder.
+
+Then you can link with:
+```
+![](../../assets/the-image.png) `
+```
+Note: image names need to follow the same convention.
+
+## Submit edits
+
+### A Casual Edit
+
+Make the change using GitHub directly. You'll need a GitHub account for this. A pull request will be created.
+
+### Heavy Users
+You'll need to fork this `documentation` repo into your own GitHub account.
+
+#### Get your own repo set up
+Create a fork of this repository on your own account,  it will look like this: `my-account/documentation`.
+
+#### Branch
+Make a new branch for each major change you are going to make. You'll always branch from your `main`.
+
+Important: don't make your edits on the  `main` branch of your fork. You'll want to keep that one clean, so you can sync from this canonical repo (there's a helpful button on the GitHub interface to do this for you).
+
+At the end of this you'll have a branch named for example: `some-new-edits`, that lives on `my-account/documentation`.
+
+##### Submit
+Then send that branch as a pull request back to the community's repo. I.e.: the `some-edits` branch of `my-account/documentation`, will then be proposed as a change to `main` of `0LNetworkCommunity/documentation`.

docs/misc/_category_.json

@@ -1,8 +1,8 @@
 {
-    "label": "Misc",
-    "position": 10,
+    "label": "Transactions",
+    "position": 2,
     "link": {
       "type": "generated-index",
-      "description": "Unsorted docs"
+      "description": "Helpful instructions for submitting transactions"
     }
 }