RetroPGF Round 3 Feedback Thread

[tjayrush]

I totally agree with this, but I might like to see a bit of randomness here as well. Maybe 10 projects, 3 of which are randomly assigned. This ensures there’s a bit of stretching and learning from the badgeholders and goes against the natural tendency of experts to already know the answers they already know. It also ensures that there’s not an “underpresented” group of projects – projects for which there are no naturally occurring “experts.”

[jaack]

Hello everyone,
Jaack from Routescan here. We applied with the Superscan, and I’d like to talk about how I think we were penalized and how the process could improve in general. What I’m writing does not need to be considered as a critique, but a constructive criticism that will hopefully lead to better outcomes in the future. I’m not mad of the outcome of this Round, whatever it may be - I really enjoyed the ride, to be honest: applying, looking at the community’s reaction, then watching the badgeholders’ discussions on Discord, and back on the RetroPGF Tracker by Growthepie.

All really as transparent as possible.

Superscan Penalization

As I saw in some articles by badgeholders that described their voting framework (no need to point out specific individuals, that’s not the point), VC funding was considered as a minus, hence some badgeholders applied a very low multiplier that would actually lower the score / amount of OP allocated (like 0.1x instead of 2x for some other aspect, for example). This is really good thought, I think, but there was no indication that we would have to report our previous funding in any other community outside OP and Ethereum. We took an grant from Avalanche in 2020 and then we made a business out of the explorer product, so we didn’t put anything in the application.

Some badgeholders thought that we were VC funded, so they applied a bad multiplier to us for this. But I can’t think of any source anywhere on the internet that tells that we’re funded, because we’re not. But I think what happened is that these badgeholders simply thought that we were funded because we have some clients, and had little time to do proper research since they had to review 642 applications in addition to ours.

Yes, we do have clients, but outside the Superchain. So for other chains we get paid for a service, while on the Superchain our goal is to get paid to provide a public good to the community. Is that a bad thing? I’m genuinely asking, I guess I’m biased on this topic.

A few improvements can be done, that require little effort to execute:

• In the application, include separate fields that applicants use to report about: Ethereum-based grants | Superchain-based grants | Other source of revenue outside the Superchain | Sources of revenue in the Superchain

• To reduce the amount of work every single badgeholder needs to do to review every project, ask badgeholders which categories they want to review, so that each badgeholder only reviews projects in a specific vertical and needs to do less context-switch that damages the review process.

Other improvements

Some thoughts on what I saw during the last 15 days of constant monitoring:

Badgeholders need to be accountable and applicants need to know what’s the status of the overall process

Many applicants were afraid of not reaching quorum (us too) because 7 days were left and only 5% of projects were eligible. We would expect that badgeholders, who were elected to do this a few weeks earlier, would take time to review and the majority would vote in the first couple of weeks, out of the 4 weeks total to vote. For badgeholders, this is a vote, but for applicants this is money, revenue and validation: if a project is not eligible, it may decide to not renew its efforts in the community, because it’s not sustainable anymore. Or a project may wait for the RetroPGF to hope for renewed visibility in the community, as projects go up and down the ranks. It seems like there should be ways to keep badgeholders accountable over the voting process, like dividing badgeholders in 4 groups (maybe divided by categories they want to vote on), and force each group to vote in a specific week of the 4-week voting timeframe, putting closed deadlines.

As the total allocation grows, more projects will apply and there needs to be a way to discard what’s not relevant or inappropriate

I see there’s an applications review period in which selected badgeholders need to review all the applciations and discard the ones that are not fit for whatever reason. But since the total allocation will grow (hopefully) even more in the future, we need to think of some way to analyze some 100,000 projects in a few weeks. I do have some ideas in this sense:

• Think about the allocation as a per-year allocation, not per-round
• Organize more rounds over the course of a year, with the same shared allocation, divided equally
• Projects that applied to one round in a year cannot apply to another round in the same year
• Projects that applied but are discarded in the first review process, can only apply once more in the same year
• Extra: each round could be related to one of the 4 categories

This system should spread the applications over a year, instead of a few weeks, and this makes way to a rotating badgeholders list that’s less fatigued by the less-huge amount of projects in a 1-out-of-4 rounds in a year.

Edit: a longer version of this feedback is on my Mirror: Ones and zeros: Thoughts on the RetroPGF Round 3 — Jaack

[Xofee]

Firstly, I’d like to extend my congratulations to the organizers, the entire Optimism ecosystem, and the badgeholders for their monumental effort! The work accomplished has been truly impressive, and I commend everyone involved for their remarkable achievements.

Moving on to areas for potential improvement, I have two main points to consider:

1. Redefining ‘Ballots/Votes’ as ‘Evaluations’:
   I suggest changing the terminology from ‘ballots’ or ‘votes’ to ‘evaluations’. This would help shift the perception that a vote is solely an endorsement. If a badgeholder believes a project doesn’t merit inclusion in the round, their evaluation should be zero, rather than abstaining to prevent the project from meeting the quorum. The objective should be to evaluate as many projects as possible and determine the value they should receive based on the ‘impact equals profit’ formula. The use of the median in this context is excellent for balancing the impact of a badgeholder who may overvalue a project or increase their votes to reach the maximum limit.

2. Adjusting the Number of Badgeholders Relative to Projects:
   The workload for badgeholders is immense, and it’s crucial to provide them with as much support as possible. One approach could be to adjust the number of badgeholders based on the number of projects to be evaluated, or vice versa. This could be achieved with the following formula:
   Number of Badgeholders = Quorum x Number of Projects / 42.
   Here, 42 represents the arbitrary minimum number of projects that a badgeholder is expected to evaluate (need to be determined).
   For example, in Round 3, with 643 projects and a quorum of 17, this would have required 260 badgeholders. This adjustment would ensure that there are sufficient evaluations for all projects to meet the quorum, provided the work is appropriately distributed (possibly by assigning each badgeholder a few random projects to evaluate).

These are my modest suggestions for enhancing the process. Once again, a hearty congratulations to everyone involved!

[nuel]

Hello op community and badgeholders, blockchainOAU need a few ballots to reach quorum, we’re Africa foremost campus/university Blockchain community, training student devs to transition to web3 and with a strong and thriving web3 community.
We appreciate if our application is given due consideration.
Please see our impact here

[lefterisjp]

I have written a long post about my voting methodology, learnings and feedback on this round here: Lefteris RPGF 3 voting rationale, learnings and feedback

[DeFi_Africa]

While we support the RetroPGF approach, we’d like to highlight a few concerns about the current round, which fortunately, we qualified for.

The requirement of 17+ ballots from badgeholders to reach a quorum feels quite cumbersome. It involves a lot of project shilling and politics, which may potentially lead to corruption or favoritism in the space. We understand the importance of voting projects to ensure they deserve the benefits they seek. However, in this retrospective funding approach, it might be disheartening to deny funds to a project that has already committed time and resources to Optimism growth just because they can’t reach the quorum.

We suggest an alternative: Let Optimism badgeholders evaluate random projects upon submission and determine their worthiness based on predefined criteria. This random project evaluation will promote fairness by ensuring that projects are not selected through biased or favoritism-driven processes, making the evaluation process more transparent. And the use of predefined criteria will ensure that badgeholders evaluate projects based on their merits and alignment with specific standards instead of just casting a ballot. This may contribute to the overall quality of retroPGF.

We are immensely grateful and excited to have participated in this round and successfully qualified for the grant. A sincere thank you to all badgeholders that believe in us and casting your ballots. Your trust in our mission is the driving force behind our commitment to advancing Optimism growth and adoption in Africa.

[jpnmemelord]

Some thoughts I wrote up the other week. Likely repeats here but want to get these out to the collective.

1. Additional clarity on applications. Disclosing VC funding, disclosing token status, and discussing crosses between application overlap (if applicable, individual/project cross over and multiple facets of a single entity) have all come up during this round and are things to consider. When viewing an app with cross over there should be a “This individual is associated with these other applications requesting funding in this round.”

2. Longer review process. Reviews took out a lot of spam, but that process had to be somewhat rushed based on volume. More time, more people, and clear guidelines on what can disqualify would help. Would make sense to potentially have a pre-review team comb through and bin applications as ‘spam’, ‘clear violation’, and ‘further review’ before passing to a secondary team that can dig further in to issues. These are different skill level and pre sorting could happen with a larger community pool of individuals while dedicated digging could be closer to the current team. Some chance an AI model could also take a pass and help with first binning.

3. Clarity and guidelines on the appeal process. There was at least one project that was voted out and then had a successful appeal based on flat denial of claims with no evidence. Appeals should have a written post to clarify to voters. There should be another vote on all appeals that is as public as the vote to remove. The ability to push applicants through without accountability is a weak point that could easily be exploited.

4. COI on lists. If lists happen again (and some lists were genuinely interesting and valuable so I think there is a reason they should) conflict of interest statements should be big and bold on apps with relevant line items in lists denoted clearly. If you make a list with COI the line item should be glaringly obvious.

[fujiar]

hello everyone

I’m looking forward to the next round where we might consider the option to differentiate between individual applications and projects in the Retro Public Good funding scheme. Why could this be a very positive step? let’s discusssssss

First and foremost, by distinguishing between individual applications and projects, we can provide more careful and specific attention. This allows badgeholders and the community to more easily assess and support initiatives that align with their respective visions and goals. In other words, it provides a more focused and in-depth approach.

Furthermore, with this differentiation, individual applications can find funding more easily and tailored to their needs, while larger projects can receive more substantial and targeted support. This creates a more dynamic and responsive ecosystem to various scales and types of contributions.

Next, this separation allows for more detailed evaluation processes. Individual applications and projects will be assessed based on more relevant parameters and criteria to their scale and scope of contribution. This can enhance transparency and ensure that every type of effort, whether big or small, receives proportional attention.

Finally, the benefit also lies in driving more active participation. Individual applications and projects might feel more motivated to contribute because they know there’s a funding path tailored to their needs. This can enhance the overall appeal of the Retro Public Good Funding program and encourage sustainable growth in this ecosystem.

So, by considering this separation for the next round, we can create a more inclusive, responsive environment and provide more precise support to contributors at various levels. Hopefully, this idea can enrich and further advance the Optimism ecosystem

[pfedprog]

Reiterating the thoughts on individual and project applications:

The Difference Between Individual and Project Applications in the Next Round of RPGF

This is my first round as a candidate in retro PGF. I have had difficult time deciding whether I should apply as an individual or a project. In the end my decision was in favour of the project since, in my humble opnion it had better reach and more impact towards the ecosystem. I am wondering what if an individual application could have lower quorom and consequently lower funding. Maybe here is a potential for further research.

[itublockchain]

Firstly, we would like to thank everyone who contributed to making this round happen. We waited for the round to end to give feedback and collected responses from our entire community. Now, with your permission, we would like to share these along with the proposed solutions:

Project/Badgeholde Ratio

In RetroPGF#2, there were 195 projects and 71 badgeholders. Two of these badgeholders didn’t vote, but that’s irrelevant. So, there were 2.74 projects per badgeholder.

In RetroPGF#3, there are 643 projects and 145 badgeholders. We know that 132 of these 145 badgeholders have voted, but as we mentioned, this is irrelevant to the main point. However, the number of projects per badgeholder in this round has increased to 4.43. This doesn’t mean that each badgeholder will review 4 projects. The most optimal impact measurement would be for each badgeholder to review every project in the round, but it’s clearly impossible for each person to review 643 projects.

Especially before this round began, we saw quite a lot of marketing moves and community updates related to this topic. We were expecting high participation. It’s almost certain that participation in future rounds will be even higher. Let’s not forget that 986 projects were eliminated during the review process. In fact, there were more than 1600 applications.

Solution Suggestion

Considering all this, we need to increase the number of badgeholders. However, in doing so, we believe badgeholders should be trusted individuals who won’t cheat in measuring impact. We need to increase the number with people who can continue to uphold this belief.

Minimum Ballot Quorum and Popularity

As far as we know, there was no minimum vote quorum in the last round. However, this round, the 17 badgeholder ratio seemed quite high. The actual problem arose from our ability to track how many ballots each project was on. A lot of dashboards created were actively used during the voting process. Badgeholders, taking advantage of the full time allotted to them, tried to review as many projects as possible, hence they didn’t create their ballots early on. As the end of the voting period approached, projects that realized they hadn’t received votes from 17 badgeholders started a shilling race on Twitter, the Governance Forum, and Discord. This led to a rush to gain as much popularity as possible in order to surpass the ballot quorum at the earliest opportunity.

Solution Suggestion

A project’s presence on ballots should not be visible until after the voting process has ended. This way, projects would focus on marketing their projects throughout the entire voting period without overdoing it. The level of project shilling that disturbs badgeholders not only causes conflict among projects but also deteriorates the experience of the badgeholders

Fund Amount That Project Need

Normally, in grant proposals, the amount of funding a project is requesting is included within the proposal itself. This is also the case for Missions happening within the Optimism ecosystem. Every project must outline what they will do, the timeline for doing it, and how much funding they need within the proposal.

Now, as we have a retrospective perspective in RetroPGF rounds, instead of asking projects ‘how much funding do you need?’, we believe we should ask ‘what costs did you encounter while creating this impact? What was the opportunity cost you lost in creating this impact?’.

This way, badgeholders will also have an idea of how much OP to allocate to projects. If there is an OP request, badgeholders can formulate thoughts like ‘yes, they have created enough impact to deserve this OP/no, they don’t deserve this OP for the impact they created, but they deserve half of it’.

Solution Suggestion

When projects apply for RetroPGF rounds, they should provide an additional piece of information: What is the cost associated with creating the impact? (This includes opportunity costs as well)

VC Funded Projects

This became a widely discussed topic, especially on Twitter following Lefteris bringing it to attention. We observed that some projects have received more investment than the total amount of grants distributed in all RetroPGF rounds to date. The contribution of these projects to the Optimism ecosystem is an undeniable fact. However, as mentioned in previous points, in a design where you receive votes based on popularity, it’s clear that funded and popular projects affect the grant amount that smaller public good projects can receive.

Solution Suggestion

We should not exclude these projects from the Optimism ecosystem, so as not to diminish their contribution. However, we cannot equate projects that have previously done fundraising with public good projects that sustain their economic viability through various grants. Therefore, we believe it would be appropriate to create a separate pool for VC funded projects in the next round’s design. We think it would be more suitable to have a VC funded project pool and an ecosystem funded public good pool in the upcoming round.

---

This post has been brought to you through the efforts of @ismailemin, @Sum, Selim, Alim, and Taylan.

[nickbtts]

Hello Jaack,

You are clearly referring to my own framework here, which has a screenshot of an early iteration of scoring. As I mentioned to you in DMs, I can only go on public information, which suggests that Routescan was spun out of AvaLabs and is actively seeking venture funding. I’ve been pretty clear that I prioritised bootstrapped teams, providing genuine open source public goods, over accelerated, funded teams that can entrench a product or service before introducing fees or withdrawing.

It may be the case that I made a mistake here. However, if you had spent as much time putting detail into your application as you did writing your substack post, then perhaps the assessment would have been different. Unfortunately Badgeholders don’t have time to go beyond said application and public information.

Edit: to note, there is no way for badgeholders to be able to submit in the first weeks, especially those who have full time commitments. It’s not a paid job and as you say yourself, you want adequate assessment.

Cheers,

Nick

[jaack]

Hi @nickbtts , yes, you are completely right.

But a couple of insights:

• we are not actively seeking funding, but we are trying to understand if someone’s interested. Blockscout did something similar 1-2 years ago
• we are not spun off from Avalanche / Ava Labs, we are an independent team.
• I have actually spent quite some time filling the application, but since I had a very limited character limits in the description fields, I prioritized highlighting the product instead of the background.

So that’s why I wrote what I wrote.

I don’t think you are accountable for this in any way, also because you put so much time into this and I really respect and admire that you tried to really do the best you could.

I was pointing out your experience as a way of pinpointing the consequences that some issues in the process have caused.

I’m really grateful that you even considered us, truly.

I hope you will use our explorer.

Thank you so much!

[casperBGD]

it was our first time to be a candidate in retro rounds
and I want to share some thoughts on procedure

• having threshold seems to be a good decision for median, but it does include stress for applicants (all round looks as elections)
• since there is threshold, maybe minimum number of ballots should be introduced to, for badgeholders, so they have to include at least 25% (for example) projects into their ballot
• when calculating median, it could be good to cut-off worst and best 20% allocations (top 20% for that project, and lowest 20% allocations for that project)
• not sure if that is possible, but more transparency in the process is needed, since you actually can see only number of ballots in for your project, no allocation, and also, you can’t see how many badgeholders actually voted, and how many didn’t
  and not sure if that is bug, but we had number of ballots going up and down during the voting process, maybe someone can explain why is that happening

and to thank everyone that had us into their voting list, but also to all that considered our project for voting

[crisgarner]

I’m an outside observer to retroPGF #3 (no proposal, no voting), I have some experience running QF rounds in Honduras, provided support to the Devcon Colombia and ETH Argentina rounds, and was part of the impact commission that supported @CryptoChica in the evaluation of RetroPGF #2. Based on this previous experience I wanted to share some feedback to improve RetroPGF #4.

First I want to echo the points that @itublockchain has mentioned with some recommendations:

Fund amount that the project needs

If a project has generated impact they know their costs, if they know their costs they can provide a more insightful request.

Recommendation

Allow the projects to list expenses and/or the requested amount. They are removing the burden from the badgeholders to assume values.

Project/Badgeholde Ratio

The more projects there are the less quality you can have in an evaluation as you have to dedicate less time per project. @lefterisjp made amazing work by spending 2-4 hours daily, which isn’t scalable for all badgeholders.

@lefterisjp

In the last month I spent 2-4 hours per day, with some days(like today) being a lot more, working on RPGF and either researching the applicant projects, or giving feedback and/or thinking on the process.

Recommendation

Accept fewer projects in total or increase badgeholders but limit the number of projects a badgeholder has to revise. This is going to be hard, as more mechanics will need to be tested like random distribution and private voting.

Minimum Ballot Quorum and Popularity

As the project saw lists and total ballots allocated in real time it turned into a shilling/popularity contest. Some projects went further and if they saw that their project wasn’t on a list messaged badgeholders to include them in a list, turning into some non-intended extortion.

Recommendation

• Badgeholders should stick to the applications. With the sheer amount of projects, it’s understandable why badgeholders used forums, spaces, and x to request applications that were underlooked, as before, this turned into a popularity contest, even worse, badgeholders might consider an impact outside of the scope requested making the audit harder of why a project was considered.

• Make lists, votes, and results private until the voting period ends.

---

I want to congratulate the community for the effort and the results, can’t wait to read more about the results. Also this a meme posted by @Jonas which reminds us that’s this an infinite game with improvements and changes each time.

Jonas 🔴✨

[Ariiellus]

GM Badge holders!

I have undertaken a thorough review and analysis of the comments provided in both this thread and the RetroPGF 3: Round Design. Through a manual count process, I have identified key observations across five distinct areas, shedding light on the community’s sentiments regarding this round. I have compiled a summary of the mentions each topic has received:

NOTE: It is important to acknowledge that the manual count process may introduce an element of subjectivity, and the results are open to interpretation. However, I believe this analysis serves as a valuable tool to identify potential pain points and areas for improvement during this round.

Below, I present a high-level overview of the comments provided, categorized by the respective areas of concern:

• Number of Projects
  • Some Badge Holders expressed feeling overwhelmed by the number of projects they were assigned to review, some of them were waiting for final lists of other Badge Holders.
  • There was an observed increase in participation rates among Badge Holders in the final days (noticed in social networks like X in the last days). Projects have to shill their projects and beg for a ballot.
  • Some applicants remarked that smaller projects with potentially impactful outcomes could be overshadowed by larger, better-funded projects.
  • Some members shown misinformation for how the OP Allocation mechanism work in this round (median) if anyone still wonder how, below is a visual explanation provided by @danftz:

• Lists
  • Participants expressed a desire for lists without OP Allocation values to encourage unbiased evaluations by other Badge Holders.
  • How to assure that a badge holder list is not inaccurate? As an experiment, a lot of these list could not been created with a high quality criteria. Despite this, lists has show to be a good tool for badge holders to scale their allocation process and get aware of projects in another areas of expertise.
• Voting Experience
  • Some members feel that the current voting outcomes do not accurately reflect the impact of some projects. As mentioned in point 1, lesser-known projects have a disadvantage in front bigger projects.
  • Different members remarked the importance of good tools such as Pairwise or the Impact Evaluation Framework for an effective project evaluation. A better UI/UX could facilitate the overwhelming evaluation process for the Badge Holders.
• Previous Funding
  • It has been a huge discussion topic about how to evaluate projects that have received previous funding, in a high level way, previous topic could be interpretate in three different ways: Previous Funding by the collective (grants, RetroPGF, Intent Missions, etc), VC Funding and last but not least, grants received by other protocols.
• Threshold
  • The most discussed centered around defining guidelines beyond the minimum number of ballots required for RetroPGF selection. Proposals included different threshold tiers with capped allocations for each tier.
  • Also, some people noticed that 0 OP allocation should not be count for quorum.

Hope this resume help everyone to have a high level understanding of what happened during this round. I believe all of your insights reflect the collective desire for a fair and efficient RetroPGF process.

[nanobro]

Analysis on @optimismFND Badgeholder distribution. Where are they from?
Full article nanobro.eth | OP Badgeholders distribution Crack down - Where are they from?

---

Shorter version

Badgeholders - Where are they from?

Let’s take a look on how we distributed badgeholders role so far.

We still dont know the top 50 of retroPGF3 yet. But when sorted by ballots. We can see almost all of them are tech projects.

If this keeps going, we’ll have stronger developers in the badgeholder army, but less voice for user adoption and governance.

The right balance not only makes reviewing retroPGF participants easier but also plays an important role in OP distribution.

We can see that the approach for retroPGF4 should differ from retroPGF3.

[Michael]

The Problem:
Badgeholders need a better way to unify their knowledge and research. In RPGF3, knowledge sharing happened through a variety of chats, X, blogs, etc. But during a review of applications, there was no way to learn “what do badgeholders know about this application?”.

This would help highlight stellar projects, spread awareness of scams & bad actors, and overall bring more context to badgeholders as they are making their decisions. This could also be a place to highlight mistakes or errors in the application.

What is needed:
A unified knowledge display on a per-application level. When I click on a project, I’d like to see all of the statements other badgeholders have made about that project.

A Solution:
Hackernews or Reddit style comment section under the project description. Comments can only be made by badgeholders or the project itself. Optionally, comments can be upvoted or downvoted by badgeholders based on their usefulness.

This approach would help unify the badgeholder knowledge which is essential as we scale RPGF to more projects and more badgeholders. Scams & bad actors are more likely to be discovered. Essential projects are more likely to be realized. And any deeper analysis done by badgeholders will be available to everyone during the voting process.

[Michael]

The problem
There is no “skin in the game” for spammers. The cost of submitting a spam application is very low, and as we all saw, this can cause a LOT of work for reviewers.

What is needed
Some way to penalize scam applicants, while providing minimal friction to legitimate applicants.

A Solution
All projects should be required to submit a small stake of 5 OP. If their project is removed for breaking the rules, this stake is not returned. All projects not removed for rule breaking get their stake returned.

There was some suggestions that projects should be able to be “sponsored” in order to reduce the cost to 0 for legitimate projects. I think this isn’t a bad idea, but does not need to be done formally at the risk of over-complicating the system. Hopefully badgeholders & others in the OP Collective would be able to informally help projects who had trouble with the staking requirement.

[pfedprog]

@Michael

The Problem:
Badgeholders need a better way to unify their knowledge and research. In RPGF3, knowledge sharing happened through a variety of chats, X, blogs, etc. But during a review of applications, there was no way to learn “what do badgeholders know about this application?”.

This would help highlight stellar projects, spread awareness of scams & bad actors, and overall bring more context to badgeholders as they are making their decisions. This could also be a place to highlight mistakes or errors in the application.

What is needed:
A unified knowledge display on a per-application level. When I click on a project, I’d like to see all of the statements other badgeholders have made about that project.

A Solution:
Hackernews or Reddit style comment section under the project description. Comments can only be made by badgeholders or the project itself. Optionally, comments can be upvoted or downvoted by badgeholders based on their usefulness.

This approach would help unify the badgeholder knowledge which is essential as we scale RPGF to more projects and more badgeholders. Scams & bad actors are more likely to be discovered. Essential projects are more likely to be realized. And any deeper analysis done by badgeholders will be available to everyone during the voting process.

Really awesome ideas and problem - solution statement.

Additionally, its vital to see the progress of the applications across rounds. Storing the data in one place in relation to the application can also help with knowledge aggregation and provide important feedback to an applicant.

[ismailemin]

@Ariiellus

I have compiled a summary of the mentions each topic has received:

Hey @Ariiellus firstly thanks for summarizing feedbacks in different categories. I have one question: I couldn’t get how “Ballots Threshold” feedbacks equals to 94 when the sum of 16 and 10 in different two topics in forum?