67p / hubot-kredits Goto Github PK

I think it would be great if we automatically tracked attendance of our Kosmos weekly calls and issued a small contribution for everyone present. I found out how we can do this easily via the API:

https://marketplace.zoom.us/docs/api-reference/zoom-api/meetings/pastmeetingparticipants

As unregistered users don't have a Zoom ID, we'll probably want to use the name field for the contributor profile (although we can add both, of course).

For contributions from Gitea and Github, we should parse the labels some more and change the category from dev to something more appropriate for the labels we think make sense. To start with, I'd propose:

• docs and documentation -> docs category
• ops -> ops category

Not sure what makes sense for design, but I'm sure it would be useful to have some labels for that be turned into the category as well.

Just happened with one from Gitea (see [email protected]):

I tried to add a contribution for raucao for https://gitea.kosmos.org/kosmos/gitea.kosmos.org/pulls/45, but I encountered an error when submitting the tx:

replacement fee too low (version=4.0.36)

Quickly checked HAL's wallet, and it contains enough ETH for any amount of fees.

Just merged the new schemas and wrapper support for validating them. Which means that contributions now expect a date, and optionally allow a time.

They're not correct in the currently recorded contributions.

Needs docs.

Idea: catch incoming webhooks and automatically create Kredits issuance proposals based on the the content.

Example case: Incoming hook for a merged GitHub PR -> create proposal to issue kredits for PR author -> post proposal link to channel.

First source to implement would be handling GitHub org-wide hook.

Some kind of incoming notification from MediaWiki should be supported for automatically proposing kredits based on edits details.

Missed this in the PR review.

Contributors who create issues and thus drive the product quality should also be rewarded.

Suggestion: Add Proposals for new github issues.

What do you think?

The codebase is starting to get a bit complex and large. We should set up a test suite and CI so we can't shoot ourselves in the foot to hard in the future.

Basically port what we have for GitHub to work with GitLab hooks. Hopefully they have org hooks, if not we'll just have to use repo hooks.

Hubot should not only notify of suggested new proposals but also once a proposal is executed.

To make proposals and the issued Kredits visible from the github issue/pr site hubot could post a comment with the link to the proposal once created or maybe only once accepted.

Turns out Gitea is not just pretty great overall, but also perfect for this use case. It supports both organization-wide webhooks, as well as custom label sets that one can select when creating a new repo. So we created a Kosmos label set, with both our preferred normal labels, as well as the kredits labels. See https://gitea.kosmos.org/kosmos/gitea.kosmos.org/labels for example.

The org hook for Kosmos can be created here: https://gitea.kosmos.org/org/kosmos/settings/hooks

We have seen contributions missing for calls, with almost every call recently.

Ideally be able to connect both Gitea and GitHub in the signup UI, before profile is created.

refs #41

1. No manually created contributor IDs (currently UUID) anymore. ID/UID has been removed, contributor.id can be used from the contract data instead.
2. Name has been removed from contributor object in contract, all profile data lives in IPFS now.
3. ipfsHash has been renamed to profileHash
4. Finding a contributor has to be done by ID instead of address now
5. Proposal URL has been removed in favor of URL in IPFS contribution doc

As our hubot runs on the same machine as the parity node we could directly connect to parity using the IPC provider - instead of through HTTP.
I assume this might be a bit more performant and reliable? causing less http requests?

https://github.com/ethereum/web3.js/blob/master/lib/web3/ipcprovider.js

On GitHub and Gitea, the reviewers should also get kredits (at least for medium/large contributions).

In order to make it easier for contributors to signup we want have some kind of oauth oracle that authenticates the users and creates a contribution profile for that user.

Example code is here: https://github.com/67P/kredits-signup

Similar to 67P/kredits-web#16 we need to store the contribution metadata in IPFS, so it can be used in proposal and token issuance records.

Ask for ETH when low, tell dev/users about incoming ETH.

We can now create ERC721 contributions directly, instead of going through a proposal.

Needs to load contributor metadata from IPFS and use the Github info from that.

Creating proposals from IRC is currently borken as it used a createProposal method that is now in the github integration script: https://github.com/67P/hubot-kredits/blob/master/index.js#L84

maybe we can even remove that feature right now (even though I think I like it) and plan a better one. The main issue right now is that the github username has to be used in the chat message and not the IRC username.

What do you think?

See dcbce66 for hotfix that doesn't really fix the underlying issue with ethers.js' wallet nonce management.

We want to ignore some repos, like e.g. https://github.com/67P/test-one-two/

Currently, it creates contributions for any meetings in the entire Zoom account that the JWT app is registered for, resulting in e.g. 5apps meetings being counted as Kosmos ones.