This means, pretty much anyone who leaves just a single comment will show up in the attribution part as a “contributor”. An this may be unexpected, or even problematic. It may seem as an endorsement of the project when they don’t want to, or just be weird to see themselves with just one comment.
For that we think we should have an opt-out. However, it sparked the question.
Can we find better ways of figuring out who we should add here?
I talked about some ideas with @decentralion on Discord and turned those into a prototype over here:
That’s my thought as well.
In the notebook I’ve implemented a few threshold strategies to tinker with.
Minimum absolute cred (as currently supported by widgets)
“You need at least 10 cred to be a contributor”
Maximum number of users (as currently supported by widgets)
“The top 50 contributors”
Note this is not listed as a filter function, but is available in the table function as limit. userTable = ƒ(users, globalCred, limit, title)
Minimum relative cred
“You need at least 1% of total cred to be a contributor”
Relative cred brackets
Core contributor (>10% of cred)
Contributor (>1% of cred)
Participant (>0.1% of cred)
Accumulative relative cred
“The first 60% of all cred is attributed to…” / “More than half of all the work gets done thanks to…”
Manually separating paid time from volunteer time, applying a threshold to volunteers only
“70% of all volunteer work is attributed to …” (the accumulative relative cred threshold)
I’ve gone back to add sliders for each table’s parameters.
Also added a new strategy of Cascading accumulative relative cred
“First 60% of all cred attributed to …, 60% of the cred earned by remaining people…, and so on”
One problem I believe there is with all relative cred based approaches is that it has increasing difficulty over time. As the total amount of cred increases, so does the absolute cred required to meet a threshold.
So a relative threshold might make sense when looking at 1 year worth of contributions. But may be completely off for 3 years worth of contributions (or 3 weeks).
If your goal is to “give credit to anyone that made a noteworthy contribution” using an absolute cred threshold may be a lot more stable definition of “noteworthy” over time.
The same could apply to the middle group of your typical 3-tier division. If you wish to split your contributors into:
Core contributors
Regular contributors
Noteworthy contributors
(drive-by contributors we don’t mention)
If you set your “regular contributors” threshold to be a relative one. People who have been regular contributors for some time but stopped, may at some point be knocked back down into the tier below that as other contributors accrue more cred. That may be what you want, if you’re looking to recognize ongoing regular contributions over historical regular contributors.
If instead you want your “regular contributors” tier to behave like a historical hall-of-fame for anyone who at some point got recognized as a regular contributor, regardless of whether they’re still active, you probably need an absolute threshold instead.
Either way, time is a really interesting factor in the relative cred scores.
A situation where I can imagine actively using different parameters is when trying to glean some community health metrics from cred.
You might use a first 80% accumulative cred of a sliding window of 5-10 weeks. As a metric of how is the work distributed between people at that time. And compare this to a 80% accumulative cred for larger windows, like per year. To find out which unique people are handling this work.
Edit: to illustrate these issues, I’ve made variations of the sfosc / sourcecred data sources. You can now pick a 2019 Q2 version and 2019 week 32 version of each to see how relative scores hold up.
It’s an important question. In the latest version of SC for instance I found myself a little disappointed that I wasn’t on the graph, as it only shows the top 5 now. It wasn’t even so much a wanting credit thing as just wanting to be able to see a visualization of my cred over time, alongside others. It’s a tricky visualization problem, as you don’t want the graph to be so noisy you can’t make meaningful interpretations. Presumably you’ll run into similar issues with other representations like avatars.
I think most of the strategies you lay out make sense. But what is optimal is going to be context dependent and time varying, as you point out. So perhaps different strategies can one day be options in the UI? I’ve also long thought that it would be valuable to have a UI that allows you to visually explore the data by tweaking parameters. But I don’t want to lose cred for thread jacking
Also, just realized this thresholding issue is going to come up in other important contexts. Basically whenever we need to create a subset of contributors. For instance, we may decide to only pay people if they contribute above a certain amount of cred. Or grant them some kind of permission in the system. For instance the ability to vote or propose votes in a governance system. Or the permission to act in a certain type of role, such as a “cred defender” who labels cred spam; in this case, the threshold may be on cred filtered through some heuristic. The list goes on.
While I’m generally against binaries, as they tend to be exclusionary and oppressive, it’s likely we’ll be forced to define and exercise binaries for certain things. Like displaying contributors in a limited amount of pixels.
This number of people to show in the visualization is the only change I have in my fork from the v0.4.0 release I use for SFOSC. I have suggested making this configurable, @decentralion pointed out it would be better to give an option to change it yourself in the browser instead of at build time and agree that would be better than trying to find the magic number.
