Yeah, I think that’s about right. IMO the current scores (at least at the user level) are mostly an activity metric. Depending on whether you think of activity as cost or benefit, you arrive at the statement above.
I think the difference is that the project will deem certain nodes as root sources of cred (cf Incorporating project goals in cred scoring), aka they are the seed vector for personalized PageRank. So the heuristic is: you get cred for creating activity that the project actually values, whereas you get resistance for activity in general.
Per the reasoning above, it depends on whether the project explicitly valued the later changes. If the later changes were a sequence of additional refactors, never enabling any project-level goals or milestones, then the whole subgraph is a swamp of resistance. Conversely, if the later changes were valued by the project (and blessed by connections to the project’s seed vectors), then the refactor gets cred too.
When I said “acquires resistance from it’s many children” I was specifically referring to a bikeshedding GitHub issue an its comments, so I meant children in the “has-parent” sense. You make a good point about how the semantics for resistance flow are domain-specific, and different from cred-flow semantics. We could imagine having “cred weights” and “resistance weights” on each edge, but that seems quite cumbersome.
- Making the post more concise likely increases the positive (cred-bearing) engagement signals, e.g. more likely to be quoted, otherwise referenced, or liked.
- We could imagine having resistance heuristics on posts wherein higher-length posts are higher-resistance.
Having feedback from humans would be most helpful here. Imagine that there’s a downvote analogue that allows people to apply additional resistance (e.g. I would love a mechanism to apply resistance to low-value meetings that I’m invited to). Then the community could apply resistance to the posts that start the bikeshedding rather than to the PR itself.