I don’t think I understand what you’re trying to propose…
Oh, ok, so here is another take from a different angle. Hope it makes sense.
Instead of inaugurating a sattelite database for the purpose of managing personal todo lists, I propose to stick with github, which the community by large has already adopted (for the worse or for the better).
This, as opposed to a sattelite data store, can efficiently leverage existing third-party tooling (
gh) and intergrate well with existing
gh enabled cli (or web ui based) workflows.
I’m aware that this perpetuates lock-in with github. Though I think consolidating workflow requirements (even around that tool), ultimately contributes to lower the switching costs.
A little oblique, but I’ve mentioned before that letting (encouraging/nudging?) people to indicate that they use or depend on packages might enable some interesting ~distributed levers.
- I think it would need to focus on carrots at first. An example would be notifications when a package you depend on:
- has been failing on hydra for [reasonable timeframe]
- is updated (maybe some subset of updates?)
- is marked/unmarked broken
- becomes unmaintained or has a maintainer change
- If the carrots do provide value and people bother signing up, it could build up a well of knowledge/experience that can help test changes, identify/develop tests that reflect real-world usage, locate new maintainers, etc.
→ I might assume that you refer to network effects?
(and occasionally/unaskedly would introduce that concept to the unbeknownst)
I do mean something different, though I didn’t intend to get deep enough into what is ultimately an aside to clarify how.
I'll tuck it into a details section to minimize disruption
There’s probably network-effecty value bound up in something like this, but it doesn’t strike me as the right focus or emphasis?
I focused the list of carrots on fairly straightforward individual benefits that might incentivize people to add themselves to a list without much concern for how or whether their total benefit scales with the length of the list.
My focus is on whether the project can add value above and beyond the time invested in creating and maintaining the system by building additional tools on top of it. (I mean something beyond just sending everyone an email and hoping a crowdsourced solution falls out.)
Some maintenance tasks are harder than necessary because the people performing them lack knowledge/experience that a package’s users have, with no great way to close the gap.
I called these “~distributed levers” because it’s probably a number of small components that, as a whole, make these lifts easier:
- enable maintainers to indicate acute needs (ex: does this change work)
- enable us to indicate systemic needs (ex: accumulate reports about whether something builds on a platform that isn’t marked supported)
- nudge package users about this need at some sensible place in close proximity to their use of the package (i.e., before/after a build)
- enable package users to collect and return the requested information in a quick low-friction manner that hopefully won’t derail their work with a big context switch
- do something context-appropriate with whatever is collected
- validate and propagate change test/feedback to the PR
- validate a test case, generate a report, and write a patch/commit/PR for it
- notify the maintainer that it’s available
I suspect experience/familiarity with a package would drive most of the value and that the value added wouldn’t continue scaling much with the number of participants once there are enough to get good, timely answers (and might roll off if low-familiarity users are providing incorrect or low-quality feedback).
Ah thanks! That totally clicked in my brain. Systemically, the issue at hand (in my words) is how to “shorten” or “close” that particular feedback loop.
We have two disparate knowledge domains, even three:
- the ones that produce a particulat piece of software
- the ones that package it for nix (our eternal bottleneck)
- the ones that use it.
In my way of looking at this, producers and consumers are already sufficiently close in open source (thanks to github/etc). If we can eliminate the need for packagers to insert themselves into that (already established) feedback loop, we might have discovered a pathway to a solution.
I might been having a similar impetus while I was redacting this “sister” post: