blog: small copy edits and corrections (#1569)

apps/docs/blog/2024-05-30-fil-retropgf-1/index.md

@@ -1,16 +1,16 @@
 ---
 slug: fil-retropgf-1
-title: "Reflections on Filecoin's First RetroPGF Round"
+title: "Reflections on Filecoin's first round of RetroPGF"
 authors: [ccerv1]
 tags: [filecoin, protocol labs network, retroactive public goods funding]
 image: ./fil-banner.png
 ---
 
 Filecoin’s first RetroPGF round ("FIL RetroPGF 1") [concluded](https://docs.google.com/spreadsheets/d/15tQZU4yfzCCso_dd5NGXfSy6XB2pmrEZzZrG_TEIKyY/edit#gid=1610641018) last week, awarding nearly 200,000 FIL to 99 (out of 106 eligible) projects.
 
-For a full discussion of the results, I strongly recommend reading [Kiran Karra’s article for CryptoEconLab](https://medium.com/cryptoeconlab/a-deepdive-into-fil-retropgf-1-results-7e5a0bcdba08). It also includes some excellent data visualizations as well as links to raw data and anonymized voting results.
+For a full discussion of the results, I strongly recommend reading [Kiran Karra’s article for CryptoEconLab](https://medium.com/cryptoeconlab/a-deepdive-into-fil-retropgf-1-results-7e5a0bcdba08). It includes some excellent data visualizations as well as links to raw data and anonymized voting results.
 
-This post will explore the results from a different angle and look specifically at three aspects:
+This post will explore the results from a different angle, looking specifically at three aspects:
 
 1. How the round compared to Optimism’s most recent round (RetroPGF3)
 2. How impact was presented to badgeholders
@@ -78,19 +78,19 @@ The one exception, of course, is the GitHub data, which we will explore in the n
 
 There were 75 projects that included a link to some form of GitHub-related impact. From this pool, Open Source Observer identified 60 applications that pointed to a standalone repository, organization, or group of related repos that could be tied to a project or team.
 
-Projects with at least one GitHub link in their application tended to perform better than projects that didn’t have any GitHub links. The 60 projects verified by OSO received a median of 2093 FIL (versus 1465 FIL) for the remaining 46 projects that were not on OSO.
+Projects with at least one GitHub link in their application tended to perform better than projects that didn’t have any GitHub links. The 60 projects verified by OSO received a median of 2135 FIL (versus 1465 FIL) for the remaining 46 projects that were not on OSO.
 
 ![image](./oso-distr.png)
 
-Some projects, like IPNI and nft.storage, include links that made their impact traceable to a single GitHub org space. Some, like Forest and Beryx, had their impact traceable to a single GitHub repo within their org space.
+Some projects, like IPNI and nft.storage, include links that made their impact traceable to a single GitHub org space. Some, like Forest and Banyan, had their impact traceable to a single GitHub repo within their org space.
 
-There were also projects that had their impact traceable to multiple org spaces OR to a space that was being claimed by a separate applicant. For instance, repos including filecoin-project/fips, filecoin-project/lotus, and filecoin-project/ref-fvm all had at least three teams claiming some form of contribution to that work. Given this was a Filecoin-focused RetroPGF round, this overlap is understandable. However, this overlap makes the analysis more complicated.
+There were also projects that had their impact traceable to multiple org spaces OR to a space that was being claimed by a separate applicant. For instance, repos including `filecoin-project/fips`, `filecoin-project/lotus`, and `filecoin-project/ref-fvm` all had at least three teams claiming some form of contribution to that work. Given this was a Filecoin-focused RetroPGF round, this overlap is understandable. However, this overlap makes the analysis more complicated.
 
-The Sankey diagram below shows a mapping between project applications and GitHub org spaces, weighted by the amount of FIL they received. A lot of FIL went towards contributions to the filecoin-project GitHub org – but it was divided over more than a dozen teams.
+The Sankey diagram below shows a mapping between project applications and GitHub org spaces, weighted by the amount of FIL they received. A lot of FIL went towards contributions to the `filecoin-project` GitHub org – but it was divided over more than a dozen teams.
 
 ![image](./sankey-funding.png)
 
-This was true not just for big projects but also for some of the smaller ones. For instance, the projects Titan Storage and Titan Network both pointed to the titannet-dao/titan-node repo.
+This was true not just for big projects but also for some of the smaller ones. For instance, the projects Titan Storage and Titan Network both pointed to the `titannet-dao/titan-node` repo.
 
 Of course, not every repo is created equally. Even if we consider a rough input to the work, such as the mythical “developer month”, we can see that some GitHub org spaces have a lot more action than others but received less funding, proportionally, for that work.
 
@@ -100,11 +100,11 @@ The Sankey graph below takes the same data as the one above, but weights it by 
 
 Whereas the first Sankey, which is weighted by FIL allocation, shows a fairly uniform distribution by project, the second Sankey, which is weighted by developer months, looks very different. There’s little correlation between FIL RetroPGF and developer months by project or GitHub org space.
 
-If we were to view each GitHub org as a project and then calculate the amount of FIL per developer month, we would see that smaller projects have a much higher ROI.
+What we see is that smaller projects had a much higher ROI. This is the opposite of what normally happens with organizations. Impact tends to compound with scale, not decay.
 
-For instance, a project that received 5000 FIL and has been running for 2 years with a 3 person team (72 developer months) would receive about 70 FIL per developer month. Compare this to a project receiving 4000 FIL over 36 developer months, ie, 140 FIL per developer month.
+For instance, consider a project that received 5000 FIL and has been running for 2 years with a 3 person team (72 developer months). This equates to about 70 FIL per developer month. Compare this to a project receiving 4000 FIL over 36 developer months, ie, 140 FIL per developer month.
 
-This is the opposite of what we normally see in the world. Impact tends to compound with scale, not decay.
+The chart below shows the relationship between developer months and FIL rewards for the 60 projects that were verified by OSO.
 
 ![image](./impact-roi.png)
 
@@ -118,7 +118,8 @@ Optimism’s RetroPGF has faced the same problem: small teams tend to receive mo
 
 All of this informs several recommendations for how future rounds of FIL RetroPGF can become more data-driven. Data can help overcome cognitive biases, lead to more objective measurement, and calibrate the round mechanics.
 
-1. **Situate projects along impact vectors, not categories.** For instance, a category like “governance” might have a north star related to “progressive decentralization”. Projects should describe (and bring easy-to-verify data) concretely how they are contributing to this, not their own version of what they think governance is about. In the near term, this means it should be easier to make apples-to-apples comparisons within an impact domain. In the long term, as the ecosystem grows larger and more complex, this could turn into focused rounds with different eligibility requirements, badgeholder constituencies, and voting mechanisms.
+1. **Situate projects along impact vectors, not categories.** For instance, a category like “governance” might have a north star related to “progressive decentralization”. Projects should describe (and bring easy-to-verify data) that shows concretely how they are contributing to this intent. They should not come up with their own version of what they think governance is about (nor should they be documenting their impact on governance by choosing the most favorable metrics to fit their storyline). In the near term, this means it should be easier to make apples-to-apples comparisons within an impact domain. In the long term, as the ecosystem grows larger and more complex, this could turn into focused rounds with different eligibility requirements, badgeholder constituencies, and voting mechanisms.
+
 2. **Try to create more standards around contributions and impact metric links.** Links have potential to introduce new information about projects that could be normalized and supplement the narrative. However, apart from GitHub links, there was very little consistency. Badgeholders would have had to click through each link and try to determine on their own what information was relevant to evaluating impact. In the near term, FIL RetroPGF should be more opinionated about the categories of links it’s interested in getting. In the long term, the most common types of links should be replaced with data widgets that projects can select to highlight their impact.
 
 3. **Reduce overlapping impact claims.** Unless you are a core contributor to a project, it can be difficult to evaluate overlapping impact claims. For instance, it is difficult to distinguish the impact of a team claiming impact for a specific pull request from the impact of a team maintaining the repo the pull request was made to (and ostensibly claiming the impact of all forms of contribution to that repo). [Hypercerts](https://hypercerts.org/) are intended to help with this type of problem. However, even if you can properly account for it, it will remain difficult for the average badgeholder to parse closely related impact claims. In the near term, FIL RetroPGF should consider limiting projects from claiming impact within the same repo or other well-defined work space. In the long run, it would be great to see hypercerts (or at least the hypercert data schema) help projects define their contributions more precisely.