Durable record of my comments from the Office hours per @decentralion request.
This also crosslinks with sourcecred governance
Item 1: We should view the source cred community as going through a three phase process
-
Level 1: Non-Adversarial, everyone engaged in the dogfooding process is genuinely invested in figuring out how best to design and use a “reputation protocol for open collaboration”. At this stage we can be less concerned about closing off attack vectors than the space of possibilities. The risks associated with exposing an attack vector are nominal and in fact if we respond effectively, we are actually stronger for having found them. [antifragility]
-
Level 2: Exploits are real, at this stage contributors who are in it for compensation begin to contribute on a regular basis and the pots of money are large enough that someone identifying an exploit could profit enough to make it worth hunting down an exploit. However, the system is still relatively young and the sums of money are controlled release enough that while this may be harmful to the community. If the maintainers identify the exploit quickly the damage will be limited and we can reasonably expect to change parameters or otherwise mitigate the risk of future exploit by the same means.
-
Level 3: large scale community, at this point a large number of contributors are aware of the algorithms, happy getting paid largely automatically based on the metrics and will be very unhappy if tweaks impact their payouts in any considerable way. While payouts are automated the level of steering in the hands of the maintainers is enough to drive the system towards KPIs be assigning the source nodes of cred based on goals or values. The idea is that the steering or nudging associated with points and rates cred is issued is enough to guide the community without being dictatorial. In this case, exposure of attacks could do serious damage so it is best if the two previous phases were successful in flushing out any major vulnerabilities.
Item 2: Who are the maintainers? I proposed that we analogies maintainers to ‘validators’ and as we advance our thinking around governance we imagine how many maintainers a project can or should have, we can use concepts like nominated or delegated proof of stake to establish representative democracy in a tokenized way but we would need governance rules that determined what is a slashable fault (flag and punish undesirable validator behavior) and how the such a fault would demonstrated and accepted. This is by no means a complete thought but it is intended as an entry point regarding future discussions around tokens. No rush, just laying some groundwork and hoping to establish some shared language.
Item 3: Concrete proposal for the first financial dogfooding: I suggested that since we are in level 1 (see item 1), that we do a collaborative review of parameters BEFORE we allocate funds. Since we are in Non-adversarial phase, i think it would be really powerful way to explore our own thoughts and feelings. The the final decisions would still fall on @decentralion but it would provide a lot more knowledge about how users might react to the different choices if we give ourselves the opportunity to have that discussion as a group. It might also increase the likelihood that we identify attack vectors. It won’t be long before start to evolve into level 2 if there is money available on an ongoing basis, so let’s learn more while we can.
Thanks, -Z
