During our last team call (3/12/20) we dove into looking at manually adding contributions for CredCon, and evaluating value/weights as a community. During this process of trying methods and testing how we talk about, evaluate, and compare the value of contributions I noticed some patterns in our conversations about each initiative.
I imagine creating something that could be a set of topics we discuss for each initiative when evaluating its value, a form filled out once an irl contribution has been made, or (eventually) a UI to help us add new contribution nodes to the graph directly.
I imagine having fields something like:
Title
Type (like project/master initiative, initiative, and nested initiative. Whatever the terminology ends up being used to delineate the scope of an initiative/contribution/action)
Description (an overview)
Concrete Value Created
Abstract Value Created
Champions
Additional Contributors
Weight
Contributions (may or may not be ānested initiativesā with their own forms)
This is all pretty loose in my mind, and Iām super open to the community deciding what kinds of terminology we want to use, or which fields/topics of discussion around value we find useful.
I also created an example to help folks get an idea of what I mean using the āarrange foodā initiative within the āCredCon master initiativeā as an example:
Thereās no real call to action here other than an invitation to think with me on the way we manage/value our manually added contributions and the process behind that.
For wording, we could do something like this, which hues to our current usage:
Initiative/ sub-Initiative/ Contribution
Or, perhaps instead of using āsubā (or ānestedā), we create a new 2nd level term such as:
Endeavor (cred placeholder to my partner, who isnāt on here)
Feat
Action
Motion
Another way to slice this could be āValue realizedā and āFuture value imaginedā. But actually a lot of the value of something abstract (e.g. team-building) will be implicitly future value? And I do like the distinction between concrete and abstract value.
Perhaps this is for another post, but do we have a default way to set weights between additional contributors? I really liked how pointing fibonacci numbers worked on the call for weighting our high-level initiatives, but imagining we might not do that for all initiatives.
One idea thatās been rattling around my head, might as well share here: default to equality. If you canāt be bothered to do the work of negotiating weights, default to equal weighting for all contributors added.
So I really liked how our weighting session worked on the last Team Call (3/12/20). It was scheduled for an hour and went three hours! Iām no fan of of long meeting generally, but when everyone on the call just keeps going of their own accord and is really productive, I think itās a good sign. Could collapse a lot of functions into one actually and save time even.
Liking the overall structure, hereās one specific suggestion I can add now.
For most Initiatives I would avoid listing additional contributors. Instead going for the contributions. And let contributors be linked to those. It avoids a āwho was relevantā style discussion at the higher level. At the more granular level itās easier to argue who contributed.
This puts some requirements on the UI, because if you need to do this manually thatās a lot of administrative work.
For code, thatās fortunately taken care off mostly by GitHub plugins. PRs have authors, which have comments and reviews, which have authors, which has commits, which have authors, etcā¦
For in-person contributions I would suggest the #props style is a good starting point.
As extensive a list of ā@person did this thing to contribute.ā as you could sanely achieve
Even if we canāt add long lists of those, itās better to frame it with what they did.
To illustrate what I mean:
Additional contributors: @a, @b, @c
An argument could be ā@b didnāt contributeā.
Sounds like a subjective value argument. āYeah they did!ā just devolves in a he said, she said.
Versus,
Contributions:
@a got groceries.
@b cleaned the counter and set the table.
@c cooked.
An argument could be ā@b didnāt clean the counter or set the tableā.
This is concrete and straightforward to refute if needed.