[Feedback needed] A new formula for airdrop and some updates

Hello to all developers participating in the Dev Airdrop!

The team has received a lot of great feedback, and we’d like to share it with all.

Feedbacks:

  • The use of tools to manipulate the number of commits can be dishonest.
  • If you want to support someone who has been supporting OSS for many years, you can use a contribution of around 5 years instead of the last year.
  • I’ve supported OSS for all these years, but last year I couldn’t do it.
  • I have a big and stable project with got many stars, the code in those is stable and the number of commits is reduced. Instead, my main contribution will be answering questions and reporting issues.

We have received reports of fraud and, as we have previously announced, we need to review our rules to deal with these.

Our hope is to support a wide range of pure OSS, from young to stable projects. Therefore we are considering the following updates

We would love to hear your feedback on this. Please tell us your thoughts.

Period: Feedback will be accepted for two days, from May 31 to June 1, 9 am UTC.

How to count contribution?

The rules currently used by the airdrop are the total number of public contributions from 1 May 2020 to 1 May 2021.

We have now created a new formula that aims to consider developers who have supported OSS for many years and exclude, to some extent, fraudulently boosted contributions.

  • Geometric mean of annual contributions over the last 5 years. By using the geometric mean instead of the arithmetic mean, the effects of temporary contribution rushes are kept small.
  • However, if you created the account less than 5 years ago, then the annual contributions made since the account was created are included. The annual contributions for the year in which this applies are the average number of contributions calculated by multiplying by 365 for the average contributions per day of the year.
  • Years with 0 contributions are counted as 1
  • Contributions include commits, pull requests, code reviews, and issues.

Here’s a simulator that allows you to see this specification:
https://jsfiddle.net/aggre/obs24vn3/

Please also try a version of 3-years: https://jsfiddle.net/aggre/obs24vn3/

Those who have a simulator result number of 500 or more are eligible.

What do you think about this rule? If there are not too many negative factors until 1 June, we are going to adopt them.

We considered including the number of followers and stars in the formula, but we agreed that it would be better not to use them in the airdrop program. Since they don’t have a time series, it’s hard to handle the submission period, and we don’t want to risk losing fairness by making the variables more complex. (Perhaps they can be adopted in another airdrop program)

Quotas

As an alternative to the rule that quotas are decremented on a first-come-first-served basis, the idea is to use sorting by a number of contributions. This would give equal opportunity to all developers, with no preference given to timezone. What do you think about this?

Entries

All entries will be reviewed, and we will exclude any illegal manipulation of the contributions.

We would love to hear your feedback on this. Please tell us your thoughts.

Period: Feedback will be accepted for two days, from May 31 to June 1, 9 am UTC.

11 Likes

I would also be excluded from the airdrop, I’ve had a GitHub account since I was 14 but haven’t always been into OSS. Nevertheless recently I’ve been doing more development.
I believe private repos should also count somehow (what about people that are building a project that they want to release later?)

I was previously eligible for the 100 DEV airdrop but now my score is only 16.

1 Like

It is understandable that token distribution on the basis of the number of contributions is not very fair. However, can more complex logic be determined? It is easy to suggest more fair and more complex logics, but who will adopt one of them? In Addition, can you implement it without any (fatal) bugs? The attack on the distribution contract was very cheap. OK, you have not hired any person who can audit contracts. OK. OK. So then, you should not waste times on building fucking github contributions counter. HIRE TRUE DEVELOPER.

thanks.

HIRE TRUE DEVELOPER. thanks. HIRE TRUE DEVELOPER. thanks. HIRE TRUE DEVELOPER. fuck. HIRE TRUE DEVELOPER.

2 Likes

Yay! Open Source FOR THE WIN!!! Thanks for the new rules, fair for the open source contributors! :slight_smile:

5 Likes

Don’t force the admin to count the private contributions since it’s not open source and that’s a bad idea, say no to Cheaters. The first post said this is for open sourcerer, why still… That’s make me sad :upside_down_face:.

4 Likes

I doubt whether there will be 200 guys that could conform ur new rules, lol

3 Likes

What if this heavily favours people who have been hired to work on open-source projects or have been able to find compensation for their work on oss enabling them to work full-time and gather up more contributions? Seems like it would lead to them benefitting significantly more, over people who haven’t had the opportunities to do so full-time but still contribute and still missing out on this airdrop.

1 Like

I am afraid the there is less than 100 people match the new rule.
only those developers who have worked exclusively in open source for more than 5 years can meet the requirements.
This rule is not appropriate for young developers who are new to the computer industry

1 Like

If you can, can you tell me what was the result of your simulation? What would be a better idea, and would you be willing to share it with us?

1 Like

I agree with the new formula, it captures way better their impact on the OSS space. Just as an example, Yukihiro Matsumoto had only 100 DEVs claimable, probably because of this exact same reason that you cited .

On another note, I’ve written about this on other chats, but we need a monetary policy to absorb the impact of this airdrop. Sharply increasing our APY and LP, just before the airdrop, for a few weeks/months and then progressively lower it until it reaches the equilibrium again on that previous emission path. Something like this.

Long term holders and old investors, liquidity providers are the ones taking all the hit from the sudden shock of monetary policy and a padding for them is needed. First movers and believers on the project, that have been through it all and still believe have to be protected, in my opinion.

This rise in APY would also create a bigger incentive for these new holders to stake their DEVs, given that L2 solutions are not in place and for some people staking is expensive. This would make them think twice about selling the token, and once staked, they would end up seeing the benefits of using DEV, and the real purpose of the airdrop would be fulfilled.

8 Likes

I think new rules are way better for the health of the protocol.

Also for young devolopers, we would love to stake for them on stakes.social. Just apply to the protocol.

4 Likes

I’m working almost full-time on tiptap for about a year. My previous score was 400 DEV. My new score is 20 :sweat_smile:

2 Likes

My score fell slightly shy of the 500 needed as I have made lots of contributions this year, but it has tailed off going back in time as I was a less experienced developer. Perhaps a weighting to more heavily favour recent years could help to solve this problem, while also including developers who have contributed a lot in previous years

2 Likes

Are you sure this is even remotely accurate?
For one, it is counting my private contributions as well. Also, given the numbers of 1103, 794, 509, 564 and 84 it calculates a score of… 79.1966367240206 ?

Also, as you saw… I only started to contribute 3-4 years ago - the time bracket of 5 years is also a bit off-putting. Maybe choose something like “the most active of the last 5 years” and maybe also count other contributions than commits, like discussions, reviews and pull requests as those usually take more time?
Not to get started on that, but “number of commits” is also a bit difficult for those of us who work on a PR against their own repo and just squash that PR in the end. But yeah. You probably won’t find a “fair” way to measure all that :confused:

1 Like

The new formula seems to be way more fair than the initially proposed one. Thank you for the modification!

I just found out that the simulator doesn’t reflect scores correctly, as data.startedAt used inside createAnnual is always undefined, unless the GraphQL query is modified to include those dates (besides endedAt). I just created a fork of the simulator which solves the problem: https://jsfiddle.net/od1nfrye/

7 Likes

I’m speaking for a friend of mine who just graduated, he was matched with the previous rules, but with the new rules he only got 34 points.his account is zhmushan.

I have 2 suggestions.

  • In addition to the original rules, limiting the new users registered in the last month (2021-4-1 ~ 2021-6-1), which can largely remove the cheating accounts.

  • manually review (but this may consume a lot of energy and may not be a good idea)

First of all: I might be a bit biased because I was eligible for the airdrop with the previous formula but not with the proposed one so take my opinion with a grain of salt :wink:

In my opinion the new formula isn’t really fairer than the previous one and mostly just punishes OSS contributors who e.g. took a year off for whatever reason or contributed a lot less in a certain year.

An OSS contributor with 5000 total contributions in the total time frame and exactly 1000 contributions per year gets a score of ~629 while a contributor with the same total amount of contributions but with 0 in e.g. 2017 and e.g. 2000 in 2016 (1000 in all other years) only gets a score of ~93 (using the jsfiddle).
I realize that this is an extreme example but with the new formula my own score is around 250 because I focused one year mostly on researching and prototyping locally (deep learning related) and didn’t “contribute” as much to the OSS community in terms of “committing a lot to GitHub”. But this period of research then lead to a lot of contributions in the following year. I guess a lot of people went through similar scenarios.

In my opinion neither of the formulas really select “valuable” OSS contributors as a single commit to a widely used repo can be “worth” a lot more than 5000 commits to a personal project which each change the README.md (I get that automatically evaluating this is more or less impossible though). Evenly spreading them out over 5 years IMO doesn’t make them more valuable as well.

In conclusion it feels like changing the formula just caters to people who were excluded from the airdrop with the prior formula and complained a lot and doesn’t really lead to a fairer distribution.
My post is basically the same (complaining about not being eligible anymore) but because the website already stated that I would be eligible it feels even more of a letdown than not being eligible from the beginning :grin:

Thanks for counting other types of contributions other than commits.

I have played a bit with the jsfiddle fixed by @kripod, and my only feedback is that, while it’s good to consider more than one year to compute the score, the 5 years shouldn’t be weighted all the same.

(disclaimer: to understand my point of view, I qualify for the 400 DEV tier with the old “count number of commits” strategy and I now have a score of 590)

Currently, an hypotetical developer who made a lot of contributions in the past and then started contributing to OSS way less (for example, 3000-2000-400-200-100 from 2016 to 2020) has a score of 544. On the other hand, a developer who created an account many years ago but just started contributing in the last few years (for example, 5-5-1000-2500-3500 from 2016 to 2020) has a score of just 185.

In my opinion this is wrong for two reasons:

  • It greatly penalizes people who are now active OSS contributors but have just started in the last few years. 5 years is a long time frame in tech, and many people could have been doing something completely different in 2016 than they are doing now.
  • By giving DEV tokens to people that are active in the OSS comminuties now, it’s more possible that they will actually use those tokens to stake other OpenSource projects. You would not be giving money for something happend 5 years ago, but giving a resource for a problem (OSS sustainability) that active OSS developers feel now. People who don’t feel the OSS sustainability problem now (even if they felt it 5 years ago) are probably way less incentivized to use those tokens for OSS rather than just selling them to take the money.

I think a better scoring system would be a weighted (potentially still geometric, even if I think in this case it’s better to have something that doesn’t privilege someone that contributed 500-500-500-500-500 vs someone who contributed 0-1000-500-0-1000) average. For example, it could be something like:

(contrib2016 * contrib2017^1.5 * contrib2018^2 * contrib2019^2.5 * contrib2020^3) ^ (1/10)

As an alternative to the rule that quotas are decremented on a first-come-first-served basis, the idea is to use sorting by a number of contributions. This would give equal opportunity to all developers, with no preference given to timezone. What do you think about this?

This is good and makes the whole system more fair. Selfishly I think “no, I can just spend the whole day in front of the computer refreshing the page and claim it first”, but it’s just better to give every person the same opportunities regardless of how much time they can spend checking the aridrop page or where they live.

4 Likes

Thanks for finding the bug!

1 Like

Thank you for sharing.

Here is a simulator that uses 3 years instead of 5: https://jsfiddle.net/aggre/obs24vn3/
He has a score of 580 in this simulator. I have heard many people say that 5 years is too long. 3 years might be a better standard.

In addition to the original rules, limiting the new users registered in the last month (2021-4-1 ~ 2021-6-1), which can largely remove the cheating accounts.

We believe that a manual review is always necessary because even older users may have used the Contribution Calendar to create art in the past. So I don’t think we need to exclude everyone who has recently registered.

3 Likes