@decentralion is unable to attend this week so I will host the meeting on my zoom account: Launch Meeting - Zoom
(@decentralion might help others if we change it in the SourceCred calendar)
During this meeting I will be reviewing and answer questions about the SourceCred research report found in this thread:
It’s on the technical side, but I am looking to make the material more broadly accessible and that start with getting feedback from the SourceCred Community!
Also please feel free to add other items to the Agenda via this thread.
@Brutalfluffy and @mzargham status of design efforts and research efforts which are progressing in parallel with engineering efforts. Design discussions revolved around preparation for the “Jam” the research discussion touch on the research report (Checkpoint: Research Report)
@Brutalfluffy and @mzargham : discussion of ways of tackling the challenge of making research more approachable to a broader audience, and a discussion of who that audience is. Our conclusion was that the audience for the research is Maintainers , as evidenced by our “dog fooding” the research serves the role of help our maintainer @decentralion make sense of results from the cred algorithm as they explore the ways to set up value and goal nodes from the SourceCred project itself, as well as select parameters such as “alpha”
Building on the research discussion, we open it to talk more broadly about the user journey of a maintainer and to begin brainstorming user stories for maintainers, since it makes sense to learn about this while @decentralion is thinking about how to initially configure the our own SourceCred instance with the Odyssey Plugin and the personalized “goal and values” based multi-dimensional Cred. (Looking for more input from @decentralion)
@Brutalfluffy imagining running a SourceCred instance for Magic Powered we brainstormed user stories,
stories (traditional management dilemma ~ ideas spoken loudest treated as most important)
“as a maintainer I need a metric which does not overvalue ‘vocalization’ of ideas over other forms of contribution”
and desires metrics that indicate “initiative” as other forms of early stage contribution
“as a maintainer I need a metric which does not overvalue contributions associated with outcomes over contributions that enable outcomes 2 to 3 or more steps removed”
and wants to make use of the data (say segment data to see how many people with high 'Engineering Cred" also say have hi “emotional labor cred” as a means of determining community structure, strengths/weaknesses, etc
“as a maintainer I wish to segment data by dimensions other that contributor”
One thing that this discussion uncovered was a kind of chicken and egg problem for a new maintainer; in order to have any meaningful opinion about how to set up a new instance of SourceCreds values and other paramters they would need to have explored the data enough to build some intuition about the structure of their community contribution network. In the Case of SourceCred itself, this has been happening already as @decentralion has been doing at part of the process of designing and developing the project. In general, one cannot assume a new maintainer will have this level of knowledge about their own projects contribution network; they may intuit the structure some, but they won’t have explored it YET, that’s why they are instancing SourceCred
“as a new maintainer, I require the ability to explore the network structure before being required to make decisions about how to configure variables or parameters I do not yet understand”
in this case we simple recommend determining some vanilla defaults aimed at giving results that are useful for the purpose of exploring the graph, and then encouraging new maintainer to customize only as a second step. When customizing we identified the fact that a maintainer will not know what number to pick or have intuition for how their choices will effect the results. So we discussed the way in which the utilities for adding manual nodes and edges visible could also be augmented to provide a visual feedback loop on the effects of the maintainers choices so that they can intuitively make selections that “feel right” the software will know what the exact number are even if the maintainer made their choices based entirely on an aesthetic feedback loop where the final choice was “what felt right to them”
All of this was initial brainstorming with the idea that future discourse thread can be started to brainstorm and curate user stories. Need @decentralion feedback and contributions. Looking at @Brutalfluffy and Denis in particular to help capture and groom. There will also need to be a thread for user stories for users (contributors)
These discussion relate back to the orignal agenda in the sense that the most immediate benefit of the research is to inform decisions around the algorithm choices and their implications. The next steps on research largely involve refactoring it to make more accessible to the broader community at both the level of understanding/benefiting from it, and at the level of building/contributing to it.
Hmm, I would think of both the maintainers and the whole community as audiences for the research. The research may be most actionable for the maintainers (in the form of said maintainers then using it to decide on parameter changes, etc). But I think understanding the research, at least at a high level, is important for the whole community. That will make cred function better, and also be more legitimate.
I’m not a typical user, since I’m already extremely invested in SourceCred. I think we’ll get more insight into this as we get some more organic usage. So far I think crypto projects are the most interested (e.g. @s-ben said a decred maintainer is interested; I just had a chat with Ryan Zurrer of Polychain who wants to use it, etc).
This is interesting to think about from a research perspective. Suppose we have some outcome we really care about. I would expect there to be only a few items that directly contributed to the outcome, but a very large number of items that are 2-3 steps removed from the outcome. So naturally, cred will accumulate at those items that are closer to the outcome. Not sure how or if we should be looking to alter these dynamics. Can we come up with some example cases?