Stockticker Webhook Refresh

[csharpfritz]

We will write some code and connect GitHub webhooks to automate the refresh of the Github widget

Data flow

• [ ] Github Webhook
• [ ] Azure Function - parse notification
• [ ] Azure Function - update datastore
• [ ] Azure Function - Notify SignalR service
• [ ] Github Widget - reload from datastore

[csharpfritz]

Good Azure webhook examples: https://github.com/mikhailshilkov/azure-functions-fsharp-examples

[csharpfritz]

Using JsonTypeProvider to read data: http://fsharp.github.io/FSharp.Data/library/JsonProvider.html

Need to remember: by default field names are initial capitalized when they are parsed

[csharpfritz]

For the GitHub statistics that we are tracking, do we count merged PRs or Commits

What is the 'correct' level of scorekeeping that we should track?

[ashleybroughton]

I noticed that the current method of tracking commits tends to favour programmers like myself who make very atomic changes (or who don't squash their commits for PR's). I actually feel this is unfair to other contributors, but I'm not sure PR tracking would balance that out either.

While PR stats would track how frequently contributors are submitting code changes, it doesn't measure the level of effort that goes into the work either. One PR might be fixing a handful of typos, another may be refactoring large swathes of code for localization (amazing work by the way essenbee - CoreWiki issue #139).

We could track both? We could track average lines of code changes per PR/Commit? Figuring out which metric is the best, really comes down to what we're trying to track.

I'm not really sure which to suggest, but at this stage I think PR's would come out more fair in terms of tracking an individuals quantity of contributions.