We do, although it looks like it's not showing on the site. I'm just fixing the issue, will update when it's there.

What's the logic here? Expected value is the same in all cases right?

Yep, the expected value remains the same, it's just a suggestion to encourage people make an entry that has a non-negligible chance of winning. As we say in the preceding sentence, there's no minimum entry size, so if you want to enter with a very long shot, that's entirely possible.

Can you share who the guarantor is this year? 

As in previous years, the lottery is guaranteed by funds held at CEA on behalf of Carl Shulman.

We currently only require an email address to make deposits under $500k (so if you have an email address that doesn't identify you then this would get you most of the way there). With larger donations we'd likely need to collect more information for KYC purposes. 

The system as described above isn't really set up to take deposits from smart contracts. The main issue is that EA Funds doesn't  take 'unrestricted' funding (as a normal charity would), and in order for us to allocate the donation correctly, we need a matching payment record from the donor (which you create when you go through the donation flow on the website) that tells us where the money should go. However, for one-off smart contract donations valued at >$10,000 we can probably work something out. Feel free to message crypto@effectivealtruism.org if you'd like to discuss further.

Thanks for this writeup. I'd also add that EA Funds accepts cryptocurrency donations, is tax-deductible in the US (501[c][3]), the UK, and the Netherlands, and doesn't charge additional fees (fees are just whatever our exchange charges us, which is typically on the order of 0. 2% or lower). Donations can be made to any of our four Funds, or to a list of ~40 supported effective non-profits.

At the moment you need to get in touch with us directly to make  donations, we support ~20 coin types, and our minimum donation size is $1,000+ or equivalent. However, we're planning to roll out a new system (integrated with the normal donation form on our website) that supports over 120 coins and will have much lower minimums in the next month or so.

(Disclosure: I'm a co-founder of EA Funds)

DAFs do make it much easier to donate appreciated stock, and this is good advice. However, if you want to make a donation of appreciated assests and you aren't able to set up a DAF, EA Funds accepts donations of stock (in the US) and cryptocurrency (US, UK, and NL) for donations of more than $1000 (no promises that you won't have to send a fax to your broker if you want to donate stock, but in general that hasn't been the case for most of our donors who are donating from Vanguard etc).

For EA Funds this is something that we’re planning to do very soon. It’s something that’s always on the backburner (as shipping features always tends to take priority), but now that there’s a new website that has much better global control of component styling, this is something where I think we can get some easy wins.

Not really (we’ve sporadically used Personas in the past, but not very systematically), but I’ve actually just been doing more reading on this. I expect that (at least for EA Funds) Jobs-to-Be-Done will be a big part of our user research project going forward.

TL;DR; – For Funds/GWWC, the frontends are React (via NextJS) running on Vercel (previously a React SPA running on Netlify). The backend is a bunch of Node.js microservices running on Heroku, connected to a Postgres DB (running on RDS), and wired together with RabbitMQ. We’ve migrated most things to TypeScript, but a lot of the backend is still JS. A lot of business logic is written in SQL/plpgSQL.

---

EA Funds and GWWC have been on the same platform since 2017, and share the same backend. 

The frontend was a pretty standard React SPA written in JavaScript, but we’re currently in the process of deprecating this for a NextJS app written in Typescript (which has been a huge win in terms of productivity). EA Funds has been ported (compare the new with the old) already, and the incoming GWWC developer will be working with me on porting the existing SPA functionality to the same NextJS-based system. The new sites are in a Git monorepo managed with Yarn Workspaces, meaning that eventually all EA Funds + CEA sites will be able to share components/login architecture/backend connections etc.

Down the React rabbithole a bit: We connect to the backend using Apollo to manage GraphQL queries, we use Immer for immutable state management as needed (though we don’t use Redux or any other global state management). UI components are provided with Material-UI.

I used to use Netlify to host the EA Funds/GWWC frontend, but we’ve moved to Vercel for their first-class NextJS support.

The backend is a collection of quasi-microservices running on Heroku, all written as Node.js apps:

• An Express web server that handles our GraphQL endpoint, as well as webhooks/callbacks for various integrations (e.g. Stripe payments). 
• The GraphQL endpoint is provided by Postgraphile, which is essentially a way of generating a GraphQL schema by reflecting over our Postgres DB. This means that we get to leverage the data structure, foreign key relationships, and type safety of the existing database for free in GraphQL. This approach means that a lot of business logic (especially around user-facing CRUD and reporting) are written directly in SQL, implemented as views and functions.
• The services are connected by a RabbitMQ message bus. Database events (e.g. “db.payment.updated”) and webhook calls (e.g. from payment processors) are pushed onto the RabbitMQ bus , so that other services can react to these events. So, if a user inserts a new payment, the Payments service can communicate with the appropriate payment processor, and when the payment status is updated as succeeded, the Emails service can send out a receipt.
• The Postgres DB is hosted on Amazon RDS.

---

In addition to EA Funds/GWWC, I’ve also helped set up a bunch of other sites used by CEA (e.g. EffectiveAltruism.org, EAGlobal.org, CentreForEffectiveAltruism.org, the GivingWhatWeCan.org homepage). Most of these are currently using the Metalsmith static site generator, which generates static HTML files that are served via Netlify. This setup has been fantastic for performance and reliability, but eventually these sites will be ported over to the NextJS monorepo for better maintainability.

---

In terms of pain points, it’s generally been a pretty solid system. The biggest challenges have been maintenance. E.g. we’ve migrated to NextJS, partly for the improved performance and DX, but also because the previous SPA was running an outdated version of React, and because of the way the boilerplate I used was architected, upgrading to a more modern version (which many packages now require) was more trouble than it was worth. Similarly, all the static sites have historically been hosted in their own repositories, which has meant that they all have slightly different ways of doing things, and improvements made to one don’t propagate to the others. Hence, the move to a monorepo, where we can share components/logic between sites. Also, the more I use TypeScript, the more I hate using vanilla JS, so I guess that’s something of a pain point in the parts of the backend that haven’t been migrated yet!

We run a pretty lightweight version of Agile. We’ve tried doing more or less of the ‘canonical’ Agile/Scrum methodologies at various points, and settled on what we have because it works for us. Basically, JP and I have a weekly meeting where we set sprint goals, broken down by number of story points (where one story point = ~ half a day of productive dev work). These tasks are added to a kanban board that we update throughout the week as things progress. We do daily check-ins with each other, and with our respective managers, to discuss progress/challenges etc. We also do a couple of pair programming sessions each week.

Tasks are triaged based on discussion with our respective managers, taking into account what seems most important to do next (itself a combination of user feedback, outstanding bugs and feature improvements, org strategy, events in the world etc). We have a loose product roadmap that informs where we expect to be going over the next quarter and year, but we don’t make concrete plans for more than a quarter away.

We’ve iterated a lot on this over the past few years, and I think that we’ve found something that works well. I like that the system is lightweight, and strikes a good balance between giving sufficient direction for what to work on, while allowing for a lot of flexibility and not getting mired in process. It also forces us to make reasonable time estimates about what we’re doing, and these are sanity-checked by another dev, which helps avoid scope creep, or underspecified tasks. Regular check-ins make it easier to stay on track – I find it very motivating to be able to show someone else the cool thing I’ve been working on and get feedback. 

I think that as we grow we’ll probably need to systematise things more. At the moment, it relies on JP and I having worked together for a long time and being very comfortable with each others’ working styles. I could imagine that as we take on additional developers, or that as the projects we’re working on diverge more significantly (as I’m now focusing almost exclusively on EA Funds) that we’d need to make some changes, probably in the direction of more concrete progress reports through the week.

For EA Funds (and the pledge management parts of GWWC), that’s me. For the Forum it’s JP. We’re both devs first and foremost though, so we get a lot of input from other people (Aaron who manages the content side of the Forum, Luke Freeman who runs GWWC, Jonas who runs EA Funds, Ben West who manages the Forum team and who is a former tech  startup CEO etc)