I fully agree that as much of this as is possible should live in the product team, but there are two different functions happening here in the post round analysis. I believe one belongs with the product teams (Not only passport) and one belongs with the program.
The product goal is to make iterative improvements so the product alone can offer a delightful and trustworthy experience.
The program goal is to ensure that the program managers, including our own, are able to assess the issues that come up in a round and use analysis to ensure they get results that will continue their communities trust in the legitimacy and credible neutrality of the round.
Here are a few things that might surprise people. I think the passports system of reputation attestation, gating, and a shared ETL layer for transparent algorithmic policy decisions which is needed for Projects and for Programs as well as identity.
We’ve discussed this need for Projects in FDD as far back as Season 13. Recently, I’ve been hearing “Project Reputation that works like Passport” from the product team. I an HIGHLY certain we will need the same thing for Programs within a year. Two years max.
However, when you ask the product team to solve a problem specific to each individual round, it crosses a known problem in working styles. Zargham is great at comparing the pace of work to its technical difficulty. The product teams don’t work at the pace the program managers need to keep the trust of their community. That is what FDD has been doing this whole time.
I suggest that a Fraud Analyst who is focused on the program managers gaining trust from their communities using our product should take a holistic view of the issues. They will look at GRANT FRAUD in addition to identity fraud. They will look at signals that combine the two. They will make recommendations to Product Managers to mitigate the current inadequacies of the products AND work with the product teams to retrospectively understand the issues which needed data analysis to mitigate.
For the reasons above, I disagree with this. But I think I figured out why we aren’t communicating this well. It is matrix of issues which confuses the situation.
Yes, Passport relies on backend analysis to close the loop. Let’s look at a happy path where Passport does in fact close the loop…
Should the Allo protocol be opinionated that preventative sybil defense is the only acceptable option?
Should retroactive sybil discounting be applied using only the Passport stamps as signals?
Retroactive sybil discounting (squelching) requires other on-chain signals which may or may not be consented to, but are public data. This is because the other non-consented pieces of information are where we find the data delta between legitimate behaviors and illegitimate ones.
Depending on how you answer these, we could place both Jobs To Be Done into Passport product:
Preventative Gating of Sybils & Retroactive Sybil Discounting (Squelching)
However, these are two distinct JTBD that should both be OPTIONS from an unopinionated primative or protocol. And each has its own loop to close.
But neither addresses the work that moves at the speed of real-time mitigation. Without this, the Program Managers lose the TRUST of their communities. These communities then lose trust in GITCOIN. Communities want to be paid out ASAP after rounds. We usually take 3-4 weeks. Product teams shouldn’t be trying to work at the pace of prioritized product development AND putting the fires out for specific rounds with real time analysis.
Check out the specific section in this article called “Clustering Workstream Modes & Frequencies in Decentralized Communities: The Socio-Technical Frequency Map” for more on the pacing issue.
This is why I’m advocating for Passport to hire a Data Analyst/Scientist who works closely with a Data Analyst on the Allo team and a Fraud Analyst on the PGF Growth/Program team.
I’m willing to learn that I am wrong on this point. Strong opinion, held loosely. But I will take the bet that program reputation is a thing at this time next year!