blog: fix formatting issue (#1565)

fix formatting issue

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

@@ -1,12 +1,12 @@
 ---
 slug: fil-retropgf-1
-title: "Reflections on Filecoin RetroPGF 1"
+title: "Reflections on Filecoin's First RetroPGF Round"
 authors: [ccerv1]
 tags: [filecoin, protocol labs network, retroactive public goods funding]
 image: ./fil-banner.png
 ---
 
-Filecoin’s first RetroPGF round [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.
+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.
 
@@ -118,9 +118,9 @@ 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) 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.
 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.
-4. **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.
+
+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.
 
 Overall, FIL RetroPGF was an exciting experiment. A large and diverse cohort of projects participated. The operations were smooth and relatively painless (as these things go). Badgeholders took their jobs seriously. There was healthy debate and discussion throughout. And, most importantly, there are 99 builder teams with more FIL in their wallets in recognition of their impact. We’re excited to support future iterations and to help the ecosystem leverage the data it needs to improve funding outcomes.