GSoD2021

[javipus]

Summary

This is my expression of interest for Google's Season of Docs program.

The project statement is still a draft and will be completed later. This is in part because some details about the proposal are unclear to me. I thought it would be beneficial for everyone to post them in public in case other writers have similar questions.

Personal information

Basic info

• My email: [email protected]
• My CV
• My GitHub profile

Writing

UMA

I am currently doing technical support for the Universal Market Access (UMA) project, a startup developing tools to streamline access to financial derivatives on the Ethereum blockchain. As part of my involvement in the project, I have developed some drafts for financial products built using their protocol. These require a combination of technical specifications and financial engineering.

• VTI UMIP proposes an implementation of the Vanguard Total Stock Market Index using UMA's infrastructure
• uFYI designs a market cap-weighted index tracking publicly traded biotechnology companies focused on longevity and anti-aging research
• uIG is a product that helps liquidity providers on Uniswap-like automated market makers hedge against price volatility

Academic writing

• I have published two proceedings papers on accelerator physics (1, 2)
• I wrote a BSc thesis on computational neuroscience, and (yet another) BSc thesis on the role of Lie theory in particle physics.

Blog

I have a (seldom updated) blog where I compile thoughts on things I read, mostly focusing on academic research I find interesting.

Metaculus

I have authored several questions on Metaculus, a forecasting platform that aggregates user predictions about the likelihood of future events. The questions are written for a lay audience, provide necessary background about the topic at hand, and establish clear criteria to adjudicate their resolution.

EA

I used to be active in my local Effective Altruism chapter, where I gave some talks:

• On cash transfers for poverty alleviation
• On charity effectiveness evaluation as done GiveWell
• On wild animal suffering

Project statement (in progress)

Project plan

I usually need to get my hands dirty to learn anything. Therefore, I expect to audit the existing documentation by following every step to the letter and writing down any hiccups I find along the way. This will serve as the backbone for any documentation changes. Analogously, I expect to start developing new tutorials by attempting to do the required tasks (cross-validation, hyperparameter tuning) and documenting every step with care.

These experiences will inform the friction log. However, since I am fully aware that my perspective is far from representative, I expect input from users will be key at this step. User feedback will be incorporated in several ways. Firstly, tasks will be prioritized using GitHub issues labeled as questions, with preference given to open issues, as the closed ones may not be relevant anymore. Secondly, a user survey could be conducted to identify pain points, ideally with some kind of incentive in place (monetary or otherwise) to make participation more attractive.

Measuring success

I strongly suggest A/B testing all the documentation developed during the project so that we don't fool ourselves and confuse correlation for causality. The details of the study design would depend exactly on the kind of docs we end up developing and whether they contain more new stuff or enhancements to previously existing material. At any rate, the release of new documentation should be staged in such a way that parts of it can be kept as controls for some of time in order to measure its true causal effect.

[vfdev-5]

@javipus thanks for your interest in our project and providing your CV, portfolio and a WIP on the project statement !

To answer your questions:

Question: Will volunteers/users be compensated to test these tasks? Or is the friction log supposed to be developed based on my observations alone? I think this point isn't super clear in the proposal and a more detailed explanation would help a lot!

The friction log can be developed based on: 1) existing github issues labeled with "question", 2) users and volunteers (we can pay them if it can help to get more feedback), 3) our subjective feedback by dev team and 4) your observations especially when you'll dive into existing docs, tutorials etc.

Question: Have you considered A/B testing success metrics? Say we develop N tutorials. It'd make sense to release N/2 first, keep rest as control (for a while). Otherwise we run the risk of confusing correlation with causality. When this data is in we can decide whether to make any changes to the remaining half.

Yes, this can be a metric too. We are open to any reasonable propositions on that as well.

[javipus]

Thanks for the thorough reply! I have edited the project statement to reflect this new info.