Thanks @kyle for your detailed budget request for S17!
I believe that the most important thing for Gitcoin Passport is the stability now.
It encountered the connectivity issues to Ceramic many times since live. (especially each grant round when the running load is high)
For the budget, is there a typo below?
Total DevRel line for Feb/Mar/Apr.
Hey. For this gitcoin budget season I will be following a different approach. I am not happy with how many things have been going in gitcoin and the way budget reviews work so I will either be abstaining or voting No in most budget reviews.
Despite the budget cuts I still think the DAO is burning too much money and it needs to become more lean.
I am more inclined to see development like this and allo get funded rather than other stuff.
Good catch, the monthly subtotals aren’t summing correctly but the season total is correct
Is passport tasked with supporting the post round sybil analysis?
I am not excited about such a huge spend on passport this quarter, would prefer a slower ramp up of the reserves.
That said I’m, in general, supportive of this proposal, but I want to ask every workstream… what would happen if this proposal didn’t pass?
Not fear mongering, just a practical reality. This post clearly explains what “yes” looks like… What would “No” look like?
Hey Griff, thanks for the questions.
Currently no, this work has lived in FDD, and the post round analysis is still up in the air where it will live in the new structures. I can see the benefit to having this happen here, or closer to the round operations work. Either way the post round analysis should be feeding back to product to ensure we enable the scaling of this work via software product development.
This is the standard 60 reserve request, because this is a new workstream Passport has no reserves and is requesting the full amount (Allo has maintained the reserves from the former GPC and you’ll see that reflected in the Allo budget request)
Totally get it, and I posed the same thought experiment to FDD on their budget. For Passport, given there are no reserves, it would stop this workstream before it started — basically a no vote on splitting GPC and a no vote on thin workstreams.
We haven’t received any pushback from stewards on this split, so it’s not a scenario we’re seriously planning for.
In the hypothetical where both budgets fail, we have less than 2 months’ runway (having brought on the devrel expenses from PGF), and it would be a best effort to meet obligations as we close up shop. I imagine most contributors would be quite distracted lining up their next jobs, and we would expect very low output and high attrition. That would also leave Passport without operations or maintenance. The DAO would need to decide what to do with the Passport product, either shutting it down, finding and staffing a new team, or finding a 3rd party team that would want to take over the development and operations of Passport.
In the hypothetical scenario where the Allo budget passed, we could try to pull the workstreams back together. The Allo budget + Reserves could just cover both workstreams operations for the season. But would completely deplete GPC workstream reserves, leaving the re-unified workstream in a precarious position.
I appreciate the question.
There are two options (likely more) that I could see:
And finally, if we decided not to fund passport at all (even after some proposed cuts), we would mostly spin down development and likely need to lay off the team. Allo could maintain the hosting, but it would stay static for a while.
I think as much work as possible should live in the product teams… especially since passport is the front end of sybil protection, and this post round analysis is the backend of the work, it seems tying these systems together under one team so the needs of each can feed back into each other. It seems that would be ideal.
On a side note, opening up donations to people without a valid passport at the end was a great call and I hope is a standard move. Let people donate and update their passport at the end of the round. Way better UX IMO.
Thank you for giving me the full spectrum of the decision at hand. I know its a hard thing to discuss… but it really helps.
I guess part of why I am asking this question is to illustrate the issues with our current system of voting and how ill suited it is for the task at hand.
Not sure of what the solution will look like next season, especially if DAOops doesn’t pass… but I would love to help make a more functional system next quarter.
I like this suggestion a lot and see Passport similarly. I have seen a lot of conversations where Passport is mischaracterized as only the front-end prevention. In truth, it relies on the continuous observations and improvements offered by the back-end analysis, and bringing those together into a single workstream feels like a natural fit to me as well.
Thanks. I agree with that as well!
I would love everyone’s input on improving the experience of working across the Grants Stack, Allo, and Passport ecosystem. I will take a minute to give a shoutout to the team that, after battling the instability with our ceramic node all round, were able to turn around a working re-architecture of Passport in less than a week to enable end-to-end stamp collection and scoring for the grace period. Shout out to Gerald, Lucian, Tim, Chibie, Erich, and Kyle. Going forward, with this architecture, we expect to have much more predictable performance under load.
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!
I’m comparing this budget to the Allo budget and am struck by a couple figures:
Top-line: Passport’s $500K vs Allo’s $800K
I’m surprised Passport’s budget is 5/8ths as big as Allo’s given that Allo has a much bigger product scope; would expect Passport to come in as a smaller share of the total previously-GPC budget. How does this stack up vs. prior seasons in terms of breakdown, and do you guys imagine this breakdown stays roughly constant in future seasons?
Devrel: Passport’s $90K vs. Allo’s $60K
Similarly, I am surprised that Passport is requesting a bigger absolute devrel budget this quarter than Allo is – since IMO, Devrel efforts should be overindexed on Allo rather than Passport. Why is Passport’s Devrel request bigger?
Thanks!
Thanks, Annika - great questions 
We have one FT contributor on parental leave, and are “borrowing” one eng from Allo. This will reset in April, and we will go back down in size. I expect the Passport team to stay lean and likely will have the budget decrease further once some of the dev rel projects are complete (more on that below).
Passport is in full DevRel build out mode, with a planned “relaunch” at the end of Feb. This means, we have a few folks working on “getting started” guides, videos and sample applications. Allo is not yet ready for this type of support and development. They will be launching a public beta at EthDenver, and the full rounds will be run in April. I would expect our DevRel budget to drop at that time, and Allo to increase quite a bit to accommodate a similar build out.
It is highly likely we will not use all of the DevRel budget we are requesting, but we wanted to leave a bit of room for opportunistic collaborations.
I hope this helps! let me know if you have more questions or see areas you want us to adjust.
As a heads up to folks - I moved this budget to Snapshot for vote!
Hoping for your support.
I voted yes on this proposal. While the budget is higher than I would expect, I’m supportive of the DAO putting in the resources for a period of time to see what is possible with building out and improving Gitcoin Passport as I think there is a lot of potential and my past interactions with it indicated to me there was significant work to be done to improve the product / user experience.
Thanks for this breakdown Kyle, all very helpful. Makes sense to me that the Product Collective has broken up into Passport & Allo—I imagine this will increase efficiency and save costs over time.
How many engineers make up the Passport Core Contributors vs Leadership/Ops?
Are the 60 day reserves just 2 months of additional runway in case unexpected costs arise? Are they returned to the treasury if unspent or rollover to the next season?
Thank you!
Currently the core Passport team is 5 engineers (one is out on parental leave), 1 PM, and 1 Designer. Leadership/Ops is a team of 3.
Correct, unspent reserves roll over to the next season, and the following season we will only request the funds from treasury needed (i.e. expected operations + 60 day reserves - current reserves)
Thanks for your interest, hope that helps you evaluate your support for the budget!
Why is there not an abstain vote in the snapshot?
Anyway I intended to vote abstain to protest the high value, but since time is running out and I am probably not gonna have access to this key till it runs out I am voting a reluctant yes since I know that development is important (though imo too expensive)
The Abstain option wasn’t set up accidentally. It was an oversight when Kyle put it up on Snapshot.
I appreciate your position regarding cost and respect whatever decision you make regarding this proposal.
Hey all - I wanted to offer some updates given this budget passed.
I posted this to Tally and wanted to share an update on the amount given the price of GTC.
Amount:
Gitcoin Passport (GP) workstream is requesting 404,750GTC* for S17. We will be leaving all reserves with the Gitcoin Allo workstream, and as a result we are requesting the full amount of reserves be funded.
*The GTC total will be adjusted based on the current market value at the time this proposal is moved to Tally. In this post, we used a $1.98 conversion rate. The vote will request the $USD amount in GTC at the lower of the current price or the 20 day moving average.
Here is a link to the Tally post: Tally | Gitcoin Proposal
Voting will go live in 48 hours.
This snapshot vote has passed with ~100% approval rate.
Metrics:
1289 unique votes
~8.2M GTC tokens cast.
To note, the number of GTC tokens cast was below average, likely because there was no “abstain” option included in this vote.
Thanks to @griff, @azeem @farque65 @bobjiang and @annika for all the time they dedicated as volunteer steward reviewers of this budget.
