Questions About Initiatives

Another question: do initiatives need to be technical (code on GitHub), or would something like designing and implementing a curation protocol qualify?

Initiatives do not need to be technical. However, initiatives should be concrete, reasonably-scoped proposals for work. I think having an initiative for a content curation protocol makes a lot of sense; however, the thread you linked looks like a brainstorm rather than an initiative. Maybe it will be the first “reference” in the initiative that comes out of that discussion.

As a heuristic, if you feel tempted to delete all of the boilerplate from the initiative category, it probably isn’t an initiative. (Part of my intention is that we’ll write a parser in the initiative plugin which parses all of the boilerplate to figure out the graph structure.)

Ok cool. I wasn’t sure if the tagging process included everything related to initiative, or actually just the initiatives themselves. Thanks for fixing that

References, actually in initiatives that means links to reference material that is useful for achieving the thing the initiative is about.

It would make sense for artifacts too I feel, but we might want to include the Contributions as a separate section as well to have higher weight edges to that in the future.

TBH the distinction between references and contributions is still a bit fuzzy in my head. Are references things that will flow Cred to the Initiative since they benefit from the Initiative’s existence, while Contributions will be things that Cred flows from the Initiative to because they helped create/support/achieve the Initiative?

The distinction in my mind is: References are not something you can directly use as a contribution. It needs a bit of “processing”. For example, a tangent discussion thread, could be a very helpful reference. But to use it towards the goal of the artifact / initiative it may need to be interpreted first.

On the other hand, a contribution is specifically for the the artifact / initiative. A PR that writes some of it’s code. But also discussion threads, if they’re specifically for designing the thing in question can be contributions imo.

For Initiatives that’s currently the case. All edge types flow cred in both directions. The weights do vary though.

Contributions for instance have a 1x forward 1x backward. Because contributions are for that initiative, it lends a lot of credibility to the initiative as well. References have a 1/2x from the initiative to the reference. And a 1/16x in reverse as this incentivizes initiatives to include many references, but doesn’t add a lot of credibility to the initiative.

1 Like

Thank you so much for explaining all that. Makes a lot more sense!

Thought about this more and I’m still a bit confused lol

Reading through pagerankGraph.js:

 * Every edge in the Graph is assigned an `EdgeWeight`, which includes a
 * `forwards` (weight from the `src` to the `dst`) and a `backwards`
 * (weight from the `dst` back to the `src`). Both `forwards` and
 * `backwards` must be nonnegative numbers. The weights influence how
 * score flows from node to node. For example, if the node `root` is
 * connected to `a` with a weight of `1` and to `b` with a weight of `2`,
 * then `b` will recieve twice as much score from `root` as `a` does.

The terms “forward” and “backward” are from the local viewpoint of a node, not the global perspective of the entire system right? For example, “forward” means from the “local” node out to other “external” nodes, but “backwards” means from “external” nodes to the “local” node. Is that correct?

  • Asking because in the past we were using the metaphor of water flowing “downstream,” but since every connection is a two-way flow that metaphor might actually make it harder for people to understand what’s going on.

From declaration.js:

/**
 * A contribution (src) CONTRIBUTES TO (verb) an initiative (dst).
 * Forward: a contribution towards the initiative is also an endorsement of the
 * value of that initiative.
 * Backward: an initiative in large part consists of it's contributions, so the
 * value of an initiative caries over to it's contributions.
 */

This doesn’t make sense to me. In my mind an Initiative exists, then people do work to contribute to the Initiative, and in return the Initiative flows Cred to contributions. Seems like it should be an exchange of energies. As is, it seems like to contribute work to Initiatives you have to also contribute Cred. Shouldn’t the Cred just flow from the Initiative to things/people who contributed to the Initiative?

Forwards and backwards are somewhat arbitrary. Let’s consider the case of an AUTHORS edge connecting a post to the person who wrote the post. There are two perspectives we could see it from:

  • we could think of the post as the “source”, and the author as the “destination”. This might make sense because cred mostly flows from the post to the author, rather than vice versa.
  • we could think of the author as the “source”, and the post as the “destination”. This might make sense because the author is the one who created the post

To me, both explanations seem plausible, which makes it hard to have a clear distinction between the “forwards” direction and the “backwards” direction. However, we needed a convention. The convention that @wchargin and myself came up with is:

Edges are named as verbs or verb phrases. For example, “@burrrata AUTHORS a post”, or “this topic REFERENCES another topic”, or “a pull request CONTRIBUTES TO an initiative”. By convention, we will consider the “FORWARD” direction of the edge to be whatever direction flows most naturally when naming the edge type, so that the source of the edge is the subject of the verb phrase, and the destination of the edge is the direct object.

Using our examples above:

Forward Edges

  • (source:author) AUTHORS (destination:post)
  • (source:post) REFERENCES (destination:topic)
  • (source:contribution) CONTRIBUTES TO (destination:initiative)

Backwards Edges

  • (destination:post) IS AUTHORED BY (source:author)
  • (destination:topic) IS REFERENCED BY (source:post)
  • (destination:initiative) IS CONTRIBUTED TO BY (source:contribution)

In general, since the direction of edges is set by semi-arbitrary linguistic convention, we need the ability for cred to flow both ways. In some cases, we really do want a bi-directional flow of cred: it makes sense that a post that I author receives some cred by virtue of having been written by a high-cred contributor, which gives it (including, e.g., its references) more weight than those written by someone who just arrived. However, cred flows more easily from the post to the author than vice-versa, which is accomplished by having a higher weight from post->author than from author->post.

Looking at the declaration, we can see this:

export const authorsPostEdgeType: EdgeType = deepFreeze({
  forwardName: "authors post",
  backwardName: "post is authored by",
  prefix: EdgeAddress.append(edgePrefix, "authors", "post"),
  defaultWeight: {forwards: 1 / 4, backwards: 1},
  description: "Connects an author to a post they've created.",
});

Notice how the forward weight (from author to post) is only 1/4, but the backward weight (from post to author) is a full (standard) 1.

In the case of initiatives and contributions: it makes sense to me that if a high-cred contribution was a contribution to an initiative, then the initiative acquires some cred for having been involved in high-cred activity. However, this could get gamed by people spuriously claiming that important contributions were contributions to their pet initiative; as with anything in SourceCred, we need to work together to ensure the integrity of the cred graph.