Post #12988

64be3f4ddaf1d88a15f3595e4c85ad2440259f18db87c6b422d4371a4085b298
465957a824a951d826f51ffdf2179e708cefd221300d6a5c7e37a266b8eef9c6
Signature not verified

This entry might be using an old signature, or it was signed by a key that does not exist on the server.

{"entry_date":1551224953,"post_data":{"edit_count":0,"last_edit_date":0,"last_edit_user_id":0,"message_sha512":"1e5e30002a714aff95be1fd93e0581be50bbe86e7f37a5735e534c4f1dfef8d79307e44f874ca9ff7fcaba09d64760622bd4e0bb326c086a6b37d44dd41c7af3","node_id":70,"post_date":1551224773,"thread_id":1676,"user_id":103},"post_link":"https:\/\/factomize.com\/forums\/index.php?threads\/1676#post-12988"}
The entry content as it exists in the database. This should be verified against the blockchain entry.
DBGrow Inc.
[USER=164]@Mike Buckingham[/USER] Thanks for the question!

The single most important task, in my mind, is onboarding more Standing Parties. Achieving this objective is critical for increasing interest and active participation in our ecosystem, is necessary to further decentralize the Protocol from a regulatory standpoint, and is even central to the safety of the Protocol -- as both the technological and social aspects of the Protocol's development are fundamental to its success.

I will also discuss a second major goal of mine which is sustaining momentum. I think it’s extremely important that we make sure to keep momentum going in our governance buildout. We have stalled a bit at times, but we need constant forward progress for Factom to become a global utility. Reducing overhead for ongoing tasks is part of this, and automating certain processes, as well as bringing other processes on-chain (which inherently automates them to some extent), can help this effort. Something Spencer at DBGrow espouses, which has had an impact on me, is the importance of properly limiting the scope of processes and discussions. This can be accomplished by properly defining the goals, and then chunking out tasks (I gave this a try with the ANO Election questions, asking limited scope questions in independent timed discussion threads, and I believe this helped keep discussion on point), as well as properly steering discussions to keep them in-line with the defined goals. Lastly, and most importantly, is to just keep the pressure on with work, week after week.

An example of sustaining momentum in a process that I facilitated was the change to RBV for Grant voting. We identified the issues around the last Grant voting mechanism, and defined the specific outcomes we wanted from a change to that voting mechanism (less ambiguity in voting strategies while still being easy for the voter to understand the system). I initially desired using STV (Single Transferable Vote) as the framework for Grant voting. However, after walking through such a solution on some calls with Julian, Canonical Ledgers, and Paul Bernier, we realized that incorporating STV, while very cool, would be a massive undertaking (as STV assumes a static number of “spaces” being voted into, and brings new dynamics such as voter subsets into play which was outside the scope of what we could manage before the Grant vote).

Faced with this reality, we pivoted to RBV, and I composed the [URL='https://docs.google.com/document/d/1AYKIR4tvosod8rz-EZpcbansIDcgddSXh0b6rgNaPnE/edit']RBV Proposal[/URL] that was presented to the community. RBV accomplished the scope of what was outlined while maintaining less complexity than STV. RBV was then swiftly incorporated into the Grant process. From my discussions, it seems it was preferable to most in comparison to the previous mechanism (except maybe to the Guides who had to do some extra counting :p), but we can continue to solidify and automate these processes. This was the first change I brought to a core Protocol process, and I look forward to making that a habit.
This is the raw content, without BBCode parsing.
Top