Productivity / Quality of Life for instance maintainers

Status: Proposal

Looking for feedback on scope.


Avatar Beanow @Beanow


This initiative is to save time and make it easier to maintain a SourceCred instance.

Running a SourceCred instance involves an increasing amount of moving parts and frustrations.

  • Somewhat confusing configuration.
  • Manually updated json ledgers, Observable notebooks and wikis for Grain distributions.
  • Slow “likes” mirroring in Discourse.
  • Maintaining a global blacklist for GitHub API quirks.
  • Manually triggering updates.
  • …and so on.

We can summarize those pain points as these areas to improve on:

  • Simplify configuration and CLI.
  • Automate / reduce instance maintainer tasks.
  • Nice to haves, further improving maintainer experience.

Once the main deliverables are implemented, we’ll create a versioned release to share these improvements.


Simplify configuration and CLI:

  • Write a design doc on a new configuration and CLI scheme.
  • Implement the new config and CLI spec as part of the instance system.

Automate / reduce instance maintainer tasks:

  • First-class support for Grain and Grain distributions.
  • Display Grain ledger information in the frontend (i.e. no longer requiring Observable notebooks).
  • Use GitHub (repositories, actions, pages) features to create an integrated maintainer workflow.
    • Create a GitHub action to update instances.
    • Cover recurring tasks (update cred, distribute/transfer grain, add identity, clear cache, update blacklist…).




1 Like

Collecting candidates in no particular order:

Taking from Refactoring the load system

@decentralion do you think this scope distinction of instance maintainer vs developer ease makes sense?

Fidelity awareness has been implemented, so this should no longer be necessary. (It hasn’t yet been in a versioned release, though, so up to you whether to edit the OP here—I’m not sure how precisely you mean “Quality of Life release”.)

by “developer ease” you mean “ease for SourceCred developers”?

Right now I would rate the QoL for instance maintainers as 1/10 (undocumented scripts, semi-published actions, out-of-date readme) and QoL for SC developers as maybe 7/10 (some weird parts, but overall codebase holds together nicely). So I definitely support prioritizing instance maintainers QoL right now.


Yes, I mean internal development, not 3rd party.

Ha! That’s a useful framing with scores. Some effort has been put into it instance maintainer experience, having docker images / actions / a readme at all. But is relatively a lot worse than the developer experience.

If you include grain distribution, I’ll agree with the 1/10.

In terms of attribution, I think it’s a big enough effort to have it’s own initiative and get the bulk of cred from there. It’s also in a close enough timeframe that I think it would be fair to reference it as a contribution here.

In terms of releases, we’re just snapshotting master and it’s already there. So it would join the v0.5.0 (initiatives) release.

I think this discrepancy suggests the initiative shouldn’t be about the release, but the push for better QoL :]

Edit: updated the title and description to reflect.

I’ve taken another stab at creating the scope for this.

Pretty happy with this new description. It means ideas like improving Discourse likes mirroring speed is a nice to have. But easy to miss suggestions, like Automatic cache invalidation move up in importance as they remove a maintainer task.

Let me know what you think of the current scope.

I’d like to focus on replacing the CLI as a well-defined first step. (With the first step for that being a design doc for the new CLI.)