-
-
Notifications
You must be signed in to change notification settings - Fork 114
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Verified contributors #474
Conversation
worker/index.js
Outdated
@@ -63,6 +64,9 @@ async function work () { | |||
await boss.work('views', views(args)) | |||
await boss.work('rankViews', rankViews(args)) | |||
|
|||
// Run once |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added this to the worker because I didn't see a nice way to add it on start-up in the main app
container. Also, this isn't really critical functionality, so I figured it made sense to put it in the separate worker process anyway. Open to feedback on this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was thinking more about adding a line to .platform/hooks/predeploy/00_build.sh
but I guess is fine here, too
Probably also easier to do it here since you already have database access
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was thinking more about adding a line to .platform/hooks/predeploy/00_build.sh but I guess is fine here, too
So add a new npm script
, or maybe just a script in the scripts
folder, then e.g. node scripts/seedContributors.js
in the build.sh? That would also be fine with me. I wasn't sure the best place, so I just stuck it here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nah, I think it's fine / better here because of no need to configure database access.
cc @ekzyis thank you for the inspiration, I like how this turned out! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK 3eaf7c9
That moment when you review a PR and think: Wait... that's it?
Looks very clean to me, nice work :)
Regarding the decoration, I think it's good but maybe it can be improved. Just not sure how exactly.
cc @ekzyis thank you for the inspiration, I like how this turned out!
Thanks, no worries :)
worker/index.js
Outdated
@@ -63,6 +64,9 @@ async function work () { | |||
await boss.work('views', views(args)) | |||
await boss.work('rankViews', rankViews(args)) | |||
|
|||
// Run once |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was thinking more about adding a line to .platform/hooks/predeploy/00_build.sh
but I guess is fine here, too
Probably also easier to do it here since you already have database access
worker/contributors.js
Outdated
* Right now, the GitHub usernames and SN nyms are not used, but maybe we'll use them | ||
* in the future for a fancier UI decoration. | ||
*/ | ||
const contributorMap = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Was thinking about pinging all persons mentioned in https://github.com/stackernews/stacker.news/graphs/contributors to ask them if they want to be added in this list
but maybe it's better to just announce this on SN when it's released and then they can respond and we add them or they create a PR 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like the idea of them opening a PR to add themselves. A little bit of proof of work to discover their user ID, plus it makes it opt-in from the get-go
3eaf7c9
to
4a11435
Compare
I mean if we're going to have a contributor map in the code, what good is it storing it in the database? |
That is a very good point, lol |
I think ideally this might be implemented as a file in the repo The people can add themselves pretty naturally. {
k00b: {
github: huumn
},
ekzyis: {
github: ekzyis
}, ....
} We could also just do a text file of newline seperated nyms if we add the ability to add other social links to a profile (which has been a persistent feature request). |
in that case, it would make sense to store it in the database since I don't think we want to tell people to create a PR to add a social link which is not Github? (Since we can't just write to the JSON during runtime else the deployed code gets into a dirty version control state which may get lost) |
I think we might be misunderstanding each other. I'm proposing that for contributors we have a flat text file
Then as a feature for every stacker, we allow them to add any number of social links to their profile so that we don't have to track the map on github. yet-another-alternativeWe don't store anything in the repo BUT we allow adding links to a profile. THEN we call github's api to see if the github usernym matches a contributor ... the only problem with this is there's no authentication. |
I think the short term mvp is probably just a file though. |
OK, so just to summarize:
Is this right? I think I had |
We probably shouldn't read and scan from disk every profile visit, so it should probably be loaded into memory (maybe as a Everything else makes sense imo |
Sorry yes that's what I meant but I didn't express it well. |
Figured! Just wanted to reduce another round just in case. |
…ion on profile page
49f6c55
to
cd771db
Compare
97d5db4
to
0e337ee
Compare
OK, I updated the PR to incorporate the feedback from yesterday's discussion. LMK what you think! |
Looks excellent. It brings me peace 🧘♂️😄 Will merge this weekend. |
Sounds good, thank you! |
Closes #471
Allow verified contributors to stacker.news to proudly display this fact on their SN profile page 🎉
Implementation details
isContributor
boolean flag added to usershideIsContributor
boolean flag added to user settings, only exposed in the UI to contributors, allowing contributors to hide that they're contributors if they wantisContributor
to true based on config that's baked into the source codeNote: I am very open to different UI for the decoration itself. I just went with something simple.