Productivity / Quality of Life for instance maintainers

The CredSperiment Initiatives
1

Status: Proposal

Looking for feedback on scope.

Champion

Avatar Beanow @Beanow


Description

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.


Deliverables

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…).

Dependencies


References


Contributions


1 Like
2

Collecting candidates in no particular order:

3

Taking from Refactoring the load system - #11 by Beanow

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

4

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”.)

5

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.

2 Likes
6

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.

7

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.

8

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.

9

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.)