gitcoinco / web

Grow Open Source
https://gitcoin.co
Other
1.78k stars 771 forks source link

The BIG Gitcoin Grants CLR Round 5 Product Feedback Thread! #6338

Closed owocki closed 4 years ago

owocki commented 4 years ago

Welcome to the BIG Gitcoin Grants CLR Round 5 Product Feedback Thread!

Grants is one of our core products, but as we've been focused on hackathons too it's the one we haven't had much time to spend devving on as much recently.

The next big effort to improove grants will be CLR round 6 (probably in Q3 sometime).

This is a thread where you can catalogue product feedback for us to work on next time.

TLDR:

owocki commented 4 years ago

round 3 feedback https://github.com/gitcoinco/web/issues/5282

GilsonCarlos commented 4 years ago

Love Round 6? YES: Extremely important, I believe that the platform needs more digital presence so that Round 6 ... 10 ... 25 ... 50 ... 250 ... 500 can reach more projects in the world. I have noticed the platform's fortified growth, but it still needs a more powerful digital presence.

Found a bug? YES: Two bugs, The platform is unstable on Firefox 74.0 (64-bit) being operated on Windows 10 Pro 64-bit, first BUG, sometimes the Feed does not update, even trying to browse or pressing F5, the second BUG, is CHAT which cannot be accessed either by the chat icon in the right corner of the screen or by the Webchat menu, sometimes it goes to the green icon allowing access by Gitcoin but the screen with a white background reappears.

owocki commented 4 years ago

sometimes the Feed does not update

which feed doesnt update?

GilsonCarlos commented 4 years ago

The Town Square that doesn't appear sometimes, but this is only happening in Firefox, in Chrome the performance is excellent.

owocki commented 4 years ago

thanks - it seems to work in my local firefox install (but im on mac not windows) i dont suppose ur running a popup blocker or anything are you?

On Mon, Mar 30, 2020 at 1:27 PM Coin Wallet Friend notifications@github.com wrote:

The Town Square that doesn't appear sometimes, but this is only happening in Firefox, in Chrome the performance is excellent.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/gitcoinco/web/issues/6338#issuecomment-606198173, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAD5PCL7P7DTDPHIBNISVP3RKDXC3ANCNFSM4LWZSPQQ .

--

@owocki http://www.twitter.com/owocki


gitcoin is live and has generated over $3.5mm for Open Source Software - see our results https://gitcoin.co/results

GilsonCarlos commented 4 years ago

There are no extensions, not even the firefox blocker, and the only antivirus I use is Lavasoft free, but I believe it does not interfere.

crisgarner commented 4 years ago

I found a bug on my Community Gitcoin Grant, not sure what did trigger it, we received a donation which is not showing on the frontend, I actually got notified of the bug by the donor. Here is the transaction

https://etherscan.io/tx/0xf3713cdb7dd0e49e155839463df6945c7f1d3ea6523648bd9d3cdd90144e88cb

owocki commented 4 years ago

@crisgarner i dont see that contribution in our DB either. can you tag the donor here so we can hear any reproduction steps?

crisgarner commented 4 years ago

Sure, I think was from @poapxyz account. EDIT: Nevermind just read https://github.com/gitcoinco/web/issues/6341

owocki commented 4 years ago

https://github.com/gitcoinco/web/issues/6333#issuecomment-607127776

RE KYC and sybill resistence

owocki commented 4 years ago

@marsrobinson had a great idea: when creating a grant, I think it should be possible to know the address upfront? https://ethereum.stackexchange.com/questions/17927/how-to-deploy-smart-contract-in-predefined-contract-address-in-private-ethereum

willsputra commented 4 years ago

cool things i'd be personally interested in... • how might we encourage grant owners to post updates about their project on the activity feed/town square? as a grant funder, i'd like to know if there's any cool updates from the projects... • an easy way to convert a hackathon project into a grant (i think @octavioamu had some idea on this?) • closer integration with High Priests (https://highpriests.rdai.money/), maybe?

owocki commented 4 years ago

i got a request on twitter today to do a better job of managing the taxonomy of grants categories/subcategories. sounds like the current approach of just letting users tag their grants isnt working

https://twitter.com/owocki/status/1246979880274653184?s=12

poapxyz commented 4 years ago

In the case of POAP we only used the "Community" category as we didn't find anything like "Identity" or "Collectibles/NFT".

owocki commented 4 years ago

from @mzargam

if you are interested here is the working draft of the paper those plots are drawn from:
May 12, 2019, 4:59 PM
you should consider, maintaining a more advanced estimator of the CLR funds which includes a projection (even its not amazingly accurate) of the total distribution of base donations, this in turn would allow you to correct for the constraint (eg the total funds allocated to CLR matching). In the first half of a CLR campaign the matching numbers grow quickly and funders and fundees alike get excited. However, this processes is a "preferential attachment style network" since grants doing well get more attention, get more donations. this of course means that you've got a fat tail distribution, and thus back of the envelope math can be misleading. All that doesn't really matter, what actually matters is the that for the projects not in the fat tail (eg most of them), as new donations spiked matches match estimates went down rapidly, and even more frustratingly (though mathematically correct), to total estimated funds (donations plus match) WENT DOWN, even as a stream of new donations went in. The algorithms you use for projections should have the requirement that under most reasonable assumptions about donation patterns the total expected should be rising with new donations. In practice this can be handled by making projections about endstate and estimating matches and totals with the endstate rather than the current state. Love the platform. Hope that helps for future iterations. -mZ
10:50 AM
oh and if you already did that and it shot way over your expected, then my recommendation is to use that estimate as the initial condition for an online ML algorithm and update your estimate of the final distribution (using a parameterized model) at each interval when you update the projections.

https://hackmd.io/@OCPoXLLVQvyCK3HvlpBEXg/SkY7VvQnV?type=view

mzargham commented 4 years ago

Cleaned up the text from the message above. Thanks @owocki.

you should consider, maintaining a more advanced estimator of the CLR funds which includes a projection (even its not amazingly accurate) of the total distribution of base donations, this in turn would allow you to correct for the constraint (eg the total funds allocated to CLR matching). In the first half of a CLR campaign the matching numbers grow quickly and funders and fundees alike get excited.

However, this processes is a preferential attachment style network since grants doing well get more attention, get more donations. this of course means that you've got a fat tail distribution, and thus back of the envelope math can be misleading. All that doesn't really matter, what actually matters is UX: for the projects not in the tail (eg most of them) as new donations spiked: estimated matched funds, and future match estimates went down rapidly, and even more frustratingly (though mathematically correct), the total estimated funds (donations plus match) WENT DOWN, even as a stream of new donations went in.

The algorithms you use for projections should have the requirement that under most reasonable assumptions about donation patterns (you can use a model eg, the one linked above to characterize those assumptions mathematically), the total expected funding on a per project basis should be rising with new donations to that project, (again falling isn't wrong per se but it feels bad).

In practice this can be handled by making projections about endstate and estimating matches and totals with the endstate rather than the current state. There are some nuances to it but nothing that should be too hard to do before the next CLR round.

Love the platform. Hope that helps for future iterations. -mZ

owocki commented 4 years ago

@vs77bb seems to think we should rename media to community round

krrisis commented 4 years ago

Okay, this thread makes things easy, thanks, bcs forgot to screenshot everytime. Things I still see that can be optimized:

For the rest: you guys rock. These are just little tiny thingies to optimize.

owocki commented 4 years ago

someone did a nice design audit for us here :) https://www.loom.com/share/f3d043d0bf7a4a8ea2996f01e8d89283?utm_medium=gif

owocki commented 4 years ago

lots of discussion on negative funding on twitter and reddit today

https://twitter.com/YalorMewn/status/1250466663167922179 https://www.reddit.com/r/ethfinance/comments/g1maq3/daily_general_discussion_april_15_2020/fngrneq?utm_source=share&utm_medium=web2x

owocki commented 4 years ago

migrate to new txn valiator script in economy/tx (which checks for the transfer event)

L-KH commented 4 years ago

I fell like I am from the future here. I am here from the daily action to have a free Kudos :) , and wanna get it while its 🔥 https://gitcoin.co/action/341/have-a-free-kudos