Tokenlog - Token-weighted backlog

Proposal Title

Tokenlog - Token-weighted backlogs

Proposal Information

Tokenlog is a new governance tool that democratizes open-source software projects by creating token-weighted backlogs.

It allows projects to continuously gather feedback from their token-holders and allows token-holders to signal which items matter to them rather than just vote on single proposals.

A better way for projects to collaborate with their biggest supporters.

Background

Tokenlog started as a hackathon project during the ETHOnline hackathon. It was inspired by the ideas and challenges of others.

Dan Finlay, Metamask

Compound, hackathon challenge
ā€œDevelop a system that makes it easier for the Compound community to coordinate governance actions; for example, where they could build a roadmap together, rather than discuss each proposal one at a time in a vacuum.ā€

The project has gained a lot of attention during the hackathon. It received 4 sponsorsā€™ prizes and several projects expressed interest to try or integrate with Tokenlog. Itā€™s currently running as a trial for a few of these, incl. Commons stack.

Why

A strong, resilient community is one that continues to develop, grow, and adapt to the changes in time and market conditions. That requires all members to be able to collaborate together and have the right tools to do so. Current governance systems however are often expensive, due to high gas fees or require high thresholds before even allowing to submit a proposal. This results in low participation rates or even worse, that smaller stakeholders delegate their tokens to a small, select group of concentrated power. While they do have the productā€™s best interest in mind, theyā€™re often not engaged in the daily operation and development of the product.

Tokenlog is planning to become part of a new stack, that allows for new development models of open-source software.

How

  • Tokenlog is permissionless and free to set-up and configure.
  • Integrates seamlessly into your Github workflow.
  • Free off-chain and gasless ETH signature voting.
  • Standard 1-token, 1-vote or quadratic voting.
  • Fully open-source.

Proposal Details

While the product is stable and already being trialed, it is still in an early-stage/state. This proposal would allow the project to move forward from a hackathon idea to a more robust, quality product.

Presentation Tokenlog // Introduction - Google PrƤsentationen
Github GitHub - wslyvh/tokenlog: Token-weighted backlog(s)
Backlog Tokenlog Ā· Token-weighted backlogs
Demo (commons-stack) Tokenlog Ā· Token-weighted backlogs
Or set-up any other Github repository using the documentation.

Expected duration or delivery date

The development of tokenlog will be an on-going effort. This proposal will focus on moving from a hackathon project to MVP. The expected duration will be ~3 months. The focus will be on a few key components, with a more loosely coupled architecture to allow for more efficient (future) integrations.

  • Data sourcing - currently only supports Github. Plan is to integrate with other community and product management tools (e.g. Discourse)
  • Data storage - currently stored on a centralized Mongo database. Plan is to move to a more decentralized and transparent storage solution that can be verified by others (e.g. IPFS)
  • Voting - currently supporting a 1-token, 1-vote mechanism, or quadratic voting on issues. Plan is to experiment with other voting mechanisms both off-/on-chain at different stages of the development process (e.g. PRā€™s or bounties)
  • Improve UI/UX design

Development of this MVP will go in parallel with more research, trial runs and interviewing of product & community managers. These results will help further drive the development and roadmap of Tokenlog. The plan for Tokenlog itself is to dogfood the solution (launch a non-transferable governance token) and reward/distribute these to other contributors (e.g Sourcecred).

Additional proposals might follow, for later stages, depending on the above research, trial runs and if we feel it would continue to benefit the Token Engineering community.

Team Information

Wesley van Heije
Iā€™m an Indie maker who likes to build products & teams, with a successful track record delivering enterprise-grade products & solutions for leading international organizations (Microsoft, Accenture). For the last 4 years, Iā€™ve focused primarily on blockchain and Ethereum (ConsenSys, Shell, Ethereum Foundation) and have developed several open-source side-projects and tools.

https://www.twitter.com/wslyvh
https://www.wslyvh.com

Funding Information

Amount of tokens requested:
ā‚¬ 5,720 EUR in stablecoin.

For the successful execution of this proposal, Iā€™m requesting a total of ā‚¬ 5,720 EUR in stablecoin, based on an average of 8 hrs/week for 13 weeks at a rate of ā‚¬ 50/hr. An additional 10% was added for contingency.

Ethereum address where funds shall be transferred:
0xcBC3Dc48Ba005cd292de77E582D5B9c55E43b95C

10 Likes

Sure, of course! Although the roadmap (and thus future proposals) will depend on more research, interviews, and learnings from earlier phase(s). A few things that Iā€™m considering at the moment are:

  1. Full & native Github integration (Github App/actions). I donā€™t believe another tool to monitor will solve much of the mentioned problems. Iā€™d like to integrate as close to the source/workflow as possible, depending on where token-holders & community members hang out most. The Tokenlog UI would offer an option to view the prioritized backlog, but shouldnā€™t be the (only) place to manage it. This could potentially on-board non-blockchain related projects into the ecosystem as well.

  2. Explore additional voting options & mechanisms. Right now you can only upvote issues and your votes remained ā€˜fixedā€™ until the issue is completed. Early feedback already suggested allowing to downvote or ā€˜unvoteā€™. Iā€™m also looking at existing open-source guidelines, such as Apacheā€™s voting committee. They provide rules for voting (+1, neutral or -1) on different action items, such as change requests, patches, releases, etc.

  3. Add on-chain activity. Right now, all voting happens off-chain. Which I think is fine for funneling in ideas & proposals as early as possible. Once these proposals start to mature and get implemented, I can imagine they require a more ā€˜officialā€™ community vote to pass. This could potentially be solved by integrating with existing solutions (e.g. Aragon, Snapshot, etcā€¦).

*) Adding on-chain activity would also allow for other directions that Iā€™ve been thinking about, such as adding bounties to items, sprints, or even money streams to contributors/teams.

On all of these, happy to discuss and get more feedback :slight_smile:

2 Likes

Super interesting proposal that can definitely lead to a pillar in communities building things together.

We have a very similar need in MetaGame, but not with github issues. Would love to chat and see how we can collaborate.

2 Likes

Hi Paco, thanks for reaching out!

While itā€™s currently not easy to pull in other data sources (than Github), this proposal (v2) should make it easier in the near future (see data sourcing). Iā€™ll DM you how to see how Tokenlog could fit in with MetaGame. Curious to hear more!

2 Likes

Definitely. Hence the proposal :slight_smile: