Upgrade to SourceCred 16 #15
Conversation
teamdandelion
force-pushed
the
upgrade-sc-dependencies
branch
2 times, most recently
from
f0b5122
to
34c6a81
Compare
teamdandelion
force-pushed
the
upgrade-sc-dependencies
branch
2 times, most recently
from
1239242
to
0110c77
Compare
This also modifies the dependencies.json, so that now we define a start period, and the Cred minting only kicks in after that period. I set the initial period to be the next logical Cred period (i.e. starting next Sunday), so if someone adopts SourceCred today, it will only start minting dependency Cred for SC in the first week where SC was already running. We should set up a GitHub action to keep moving the start date to next Sunday. Test plan: `yarn load; yarn graph; yarn score; yarn site; yarn serve` and verify that there are no errors.
teamdandelion
force-pushed
the
upgrade-sc-dependencies
branch
from
0110c77
to
b8327e3
Compare
| @@ -2,6 +2,8 @@ | |||
| { | |||
| "autoActivateOnIdentityCreation": true, | |||
| "name": "SourceCred", | |||
| "startWeight": 0.05 | |||
| "periods": [ | |||
| {"startTime": "2020-09-20", "weight": 0.05} | |||
There was a problem hiding this comment.
IMO it would make more sense to set this when the user first runs the instance instead of trying to keep it up to date with a Github Action. We can do it at the same time we generate the ID for the SourceCred user.
Reasons why:
- Cleaner commit history (important for users to know how to update their instances with latest changes if we add new config files / features, etc
- User doesn't end up with that action running in their repo when they fork it
- Updating it every week would be inaccurate since forking it the day before it updates would mean the start time gets activated in 1 day instead of 1 week.
There was a problem hiding this comment.
@HammadJ it seems like you are using this change to make a larger suggestion about the design for interaction between instances and SourceCred itself.
You want to see SourceCred be able to dynamically update an instance so user's can see these changes for themselves in the diff after upgrading their sourceCred dep. I think this is a great idea, but but should this upgraded design prevent this change from merging?
I'm approving because I think we can accommodate this change in the new design you are proposing, and keep with our "incrementalist" philosophy here.
| @@ -2,6 +2,8 @@ | |||
| { | |||
| "autoActivateOnIdentityCreation": true, | |||
| "name": "SourceCred", | |||
| "startWeight": 0.05 | |||
| "periods": [ | |||
| {"startTime": "2020-09-20", "weight": 0.05} | |||
There was a problem hiding this comment.
@HammadJ it seems like you are using this change to make a larger suggestion about the design for interaction between instances and SourceCred itself.
You want to see SourceCred be able to dynamically update an instance so user's can see these changes for themselves in the diff after upgrading their sourceCred dep. I think this is a great idea, but but should this upgraded design prevent this change from merging?
I'm approving because I think we can accommodate this change in the new design you are proposing, and keep with our "incrementalist" philosophy here.
This also modifies the dependencies.json, so that now we define a start
period, and the Cred minting only kicks in after that period. I set the
initial period to be the next logical Cred period (i.e. starting next
Sunday), so if someone adopts SourceCred today, it will only start
minting dependency Cred for SC in the first week where SC was already
running. We should set up a GitHub action to keep moving the start date
to next Sunday.
Test plan:
yarn load; yarn graph; yarn score; yarn site; yarn serveand verify that there are no errors.