Gitcoin Hackathon Sponsor Feedback & Conclusions

gitcoin_hackathon_sponsor_feedback_conclusions.md

Gitcoin Hackathon Sponsor Feedback & Conclusions

Problem(s)

1. Paying sponsors don't feel exclusive & special, and feel like they're competing with other sponsors.

   • PoolTogether: "We will use bounties for sure, but probably will post our own hack on Gitcoin."
   • ETC: "I feel like our bounties got croweded out by other sponsors. Aave seemed to have alot of activity."
   • Blockstack: "We're price conscious, that does come into play, if we increase prize and cost of the hackathon, moving forward, if there was a way to host a hackathon, and not partake in the majority of the marketing (2k price tag, vs 6-8k), we would definitely return to Gitcoin."
   • Zcash/ECC: "There were so many sponsors in one hack, the ROI was not worth it. What do we actually get at each tier? I expected analytics with the tier we had. The event planning and execution felt adhoc based on the level paid. The event started off strong with customer service, but it petered off hard, it felt like we got less and less service as the hack went on. It would be hard to justify a budget like that again, unless we are 100% sure we understand what we've committing to, e.g making sure the hackathon levels are clear on what they get."

2. Paying sponsors don't know how their progressing or the ROI from Quests & Kudos.

   • RenVM: "How's the hackathon going? It's hard to answer what is actually happening. It's tough to suss out who were actually serious about doing something vs. people who are just joining."
   • Blockstack: "Quests have limited ROI, I'm not sure if it's worth attention or engagement. Same with Kudos, limited ROI and distracts from the core mechanism."
   • Zcash/ECC: "There's no analytics, I don't know the performance of how my hack is doing. Also, no Quest or Kudos analytics, unknown ROI there."

3. Featured communication tools on Gitcoin were very confusing.

   • PoolTogether: "It's alot of stuff. Need to pare back. Hard to track what was going on. Had no idea what the townsquare / chat was."
   • RenVM: "Gitcoin chat, there wasn't a ton of convo, but if there was more I'd move after. There was a bug with chat. Couldn't send a message through. I probably would have gone with Telegram."
   • ETC: "We usually talk on Github for the technical stuff or DM them on Telegram or Discord, and only used Gitcoin chat for notifying the winner. Gitcoin chat is a little too stimulating."
   • Synthetix: "Mainly communicated on the Github repo housing potential improvements and proposals, but lots of balls to juggle. Let's try to do something which is set up and manages itself."
   • Quantstamp: "Web chat in top right hand corner is different from Townsquare. There was no activity in them and that was very confusing. Maybe we have automated reminders in the main chat, but there needs to be a constant base of people liquidity. Maybe hackathon townsquare should be hackathon annoucements, it's confusing with the homepage Gitcoin townsquare. It feels like Facebook, with way too many things to do. Chat can get people really really lost especially if its empty and you can find it everywhere."
   • Biconomy Labs: "Comms were confusing with multiple chat channels, we just ended up using Github for communications and Github comments, maybe mobile notifications would be useful for Gitcoin chat, but overall it was confusing, and we were not aware of the Gitcoin channels we had. Most hackathons have a Discord channel, and it's just figuring out the right platform to use."
   • Blockstack: "Communications were mainly with Blockstack Discord (already created), great culture of collaborations, but Gitcoin's chats were essentially replicating things with townsquare and chat, and Gitcoin chat is a little noisy, and an email is sent every time, which is annoying. There's definitely feature overload, especially with the comms channels. Although, I didn't mind townsquare, I liked how it showed up on the main page."
   • Zcash/ECC: "Gitcoin chat with company specific channels and Gitcoin everything chat, hackathon Townsquare, regular Townsquare, no hackathon focused communications, all of this was very very confusing."

4. Looping back with hackers that did a great job is difficult.

   • Blockstack: "Hackers after the hack have developed a smart contract library, and we helped catalogue them."
   • ECC/Zcash: "It's really hard to continue the relationship if everything is built on a hackathon specific rather than a company specific channel. I don't know if I'm ever going to see [a top hacker] again. The loop is very hard to close. We got a spreadsheet of the people who joined our hack, so submitted work and inviting folks into our Discord, there were some continuities there, but very adhoc. We use gitcoin because of the network, the network is the value."

5. Judging is backwards.

   • Zcash/ECC: "Judging is weird. Usually in a normal hack everyone presents and demos, judges give feedback to everyone, then determine winners. Gitcoin is backwards, everyone submits, we judge, and then there's a demo day/pitch, no feedback given to non-winners. A guy did a youtube pitch because he knew he wasn't gonna get a chance to do it."

6. There's not enough serious developers coming to us.

   • PoolTogether: "Where should I have gone to get developers?"
   • ETC: "There wasn't too much participation, and it would be nice to see if there’s a member of the Gitcoin or ETC team to check on engagement with bounties to see how we can pivot. How can we somehow show to people that there's activity on these bounties?"
   • Synthetix: "When participating, we like to be hands off. How can we ensure our bandwidth isn't affected?"
   • Quantstamp: "Doing things with HackMoney got us more attention."

Solutioning:

1. Playing the long-term game here is paramount with regards to hackathon deal structure. I suggest that a sponsor gets singular attention, like Filecoin, Matic, or Arweave. This potentially means no overlapping hackathons which means a huge relief on the operations team, and less crazy coordination skills for 5+ sponsors in just one hack. 50%+ of the sponsors are already saying they don't like the competition multiple sponsorships entails, and combined with the other problems, they may not do another hackathon at a similar price point. If we don't have repeat customers, we have no long term game.

2. Setting up in-app hackathon analytics would be the solution to "no analytics." Another decision is if we want to remove Quests and Kudos. The question I leave here to determine that is, does it dilute from the main mechanism that sponsors are looking for? At the end of the day, as a sponsor, if I had lots of people playing Quests and giving Kudos, but had no submissions, I'd be sad. This is an optionality that we can possibly remove for the time being. This has the added benefit of reducing the operational load.

3. It is painfully evident from every sponsor that chat is "confusing, confusing, confusing", and is really diluting the clarity of sponsor actions. I vote to remove chat in all locations, but keep Townsquare for annoucements only.

4. Looping back with hackers is currently taken care of when sponsors follow up with Gitcoin users from a hack, but we still have to provide contact information. Perhaps there isn't a product that will be used to "connect hackers to sponsors" but more that Gitcoin is a data moat and we have a specific brand like a "Gitcoin-sprouted developer", that can hop to anywhere else (any Telegram or Discord), but our sponsors know Gitcoin developers are legit since they've done good work here.

5. No solution yet.

6. The solution here is more oriented towards operations. Early start and adequate vetting of applications will help garner good attention early, so we scramble less. Singular-sponsor, non-overlapping sponsor hackathons also spreads out the work a little better, and hackers potentially can have more focus this way.

Overall Solution / Reduced Experience

Specifically from the product side, this results in a highly reduced hackathon experience:

• Sponsor signs on the dotted line.
  • 2-3 week lead time
  • specific sponsor hack dates
  • sponsor funds issues
  • [way to funnel registrants to sponsor chat channels]
• Sponsor hack starts.
  • sponsor can check hacker/user analytics
  • sponsor participates in workshops
  • sponsor participates in livestream
  • [sponsor participates in conversations in sponsor chat channels]
  • announcements are made in townsquare
• Sponsor hack ends.
  • sponsor retro data report
  • sponsor judging
  • sponsor payout
  • [sponsor participates in demo day]
  • sponsor already has folks in their chat of choice

Appetite:

How interesting is this problem to our Gitcoin core development team? [Core Gitcoin engineering and et al to answer.]

Fixed Time:

A minimal solution can be merged and deployed in [4] weeks time.

Variable Scope:

TBD

Where are the grab bags to avoid (v1.0, v2.0, v3.0, etc)?

1. We are not solving for sponsors being able to see a Tribe.
2. We are not ... etc.

Where are the rabbit holes to avoid and no go situations?

1. Does this require new technical work we’ve never done before?
2. Are we making assumptions about how the parts fit together?
3. Are there any hard decisions we should settle in advance so it doesn’t trip up the engineering team?