Having direct PRs is error-prone as more people sign.
People could contribute to a different file, and then you can generate the index.html page periodically with a script so it's always kept alphabetical.
Trying this route here:
One benefit of the way it's done now is that it's very easy to validate who people are with Twitter or Github PRs. I'm not sure building up to a web form is the right idea.
Already thought about this, if you see the repo I have a empty confirm component which is meant to do this.
Ideally, will pass github username and then can scrape and confirm the name matches the github
Also why I added the confirmed, default=0
Can github host what you're creating though? I assume this is built as a free github.io site.
This is a free github.io from when I digged and whois; I was thinking serverless (lambda) - first million requests are free
Otherwise, I can host it myself.
Github pages are built with Jekyll. This doesn't need some web service with a form and all that. Just a cron job that builds and pushes it once an hour or so.
Cron job what is this 2005? At minimum webhook on pull request to build and then merge
If need be I can volunteer myself for doing the automation piece if whomever can make me a contributer.
I have a jenkins server of five somewhere i can run some basic sanity checks in
Although; i think really if this evolves into something static html is introducing technical debt from the get go
@akeri, would love to hear your thoughts on why you down voted this... I tend to develop everything for scale. Introducing technical debt for the sake of functionality means your making more work for yourself. You never know what is going to evolve and grow.
I guess the real question is, would you rather do it right the first time or spend extra time in the future to fix your initial code?
Could you imagine having to review every pull request for one line of code?
It's 2016; if it's not automated it's dead. (my opinion)
@morissette This is not a constructive way to talk: "Cron job what is this 2005?"
@mezz @binford2k I started a PR to use Jekyll's collections, which a really designed for this sort of thing! You can see an example at https://github.com/amc-workshop/amc-workshop.github.io I made a PR trying to do the same thing here: #472
Thanks for the idea, I can't believe I didn't consider it sooner!!
Pull request is tested and works great except new signatures aren't alphabetized with the rest of the signatures. I think given the amount of error-prone merging this avoids it's worth it. Thoughts?
@emhoracek - agreed. I just find cron jobs so out of date at this time.
As for the web services - this is meant for if this page grows into something larger than a signature page :).
This could be made a lot simpler with a directory structure like this:
Then add a test that checks that /signers/*.json all conform to this spec while validating the existence of the profiles claimed:
"github": "<something valid>",
"twitter": "<something valid>",
"website": "<something valid>",
"comment": "<something valid>"
Then just have a script that regenerates index.html on merge. That gives @morissette the automation he's looking for and the extendability this issue is calling for.
@danielquinn What you describe is very similar to the PR I made, except my PR uses the system GithubPages already uses (Jekyll), so is lower friction.
Resolved by #529 and further by #648
Cool, glad this made it in before the real avalanche of new PRs!
I can imagine this going exponential for a little while.