Open nickbtts opened 3 years ago
That might be a smart way to keep the noise level down and make the proposal process more streamlined. Then again, so far the amount of proposals here so far is limited, so i am not so sure how much its needed currently, but for the long term i think its a great idea.
This Github issue tracker should have tags for issues, e.g. "Proposal", "Discussion", etc.
I agree we need a formal process and a quorum but the proposed multi-step might be too slow.
I would like to propose taking things a step further, either in this proposal or as something standalone, to outline what can and can't be made a proposal, what the multisig holders will and won't get involved in, if there are powers of veto in the process and who those people are.
It seems logical to discuss whether the spend of 2 ETH or the granting of 1 LOBS for a listing on Rarity Tools, to discuss changing specifics of the multisig contracts for additional safety or to fund community development of rarity trait data, but what if someone took a serious proposal forward to buy Berghain - aside from the various challenges that could be involved - could a DAO even buy a bricks and mortar building etc etc - our Multisig holders inevitably would have to sign off on this.
I believe the DAO needs a constitution, collaboratively drafted and adopted that outlines just how far the autonomy is to go, who oversees (if anyone) adherance to governance rules, what the DAOs goals and objectives are
Big supporter of this. I don't have much of an opinion on the exact way it is implemented.
I agree with @Dogetoshi. We need to semi-ossify the governance process, though the multistep process could slow things down too much at this early stage. The min LOBS threshold (5-6) Ivan setup for snapshots should be sufficient for now is my rudimentary thought.
In light of the comments above, we may want governance to remain dynamic. It's definitely up for discussion whether we want any 'blockers' inserted in the future, but in the meantime, here is a brief idea for how we can tidy up the process so that quality proposals stand out.
Discussion in github. Issues should be prefixed with [Discussion], [Proposal], [Technical] or [Urgent]. I'd like to see some sort of signalling...we could use https://gh-polls.com/, but it's slightly technical. Maybe we could use Commonwealth plugged into Snapshot?
See below for template.
LIP#: <# to be assigned>
Title: <LIP title>
Author(s): <list of authors' Telegram handles or wallet address if anon>
Contributors:
Nominated Proposer: <Should be arranged in advance if author is ngmi/has not enough lobs>
Date Proposed: <yyyy-mm-dd>
Date Ends: <yyyy-mm-dd>
Replaces: <List of LIP it is replacing>
Amazing!
I am for that proposal have to reach quorum (10-30%?) before make it to voting.
In regards to "real" governance. We could draft Articles of Association and sign them with our wallets. Could lay out governance in a real meatspace way and could be drafted to incorporate blockchain governance architecture. Given the chorus of "do something, don't expect it to be done", I could voluntary my services pro bono for such a project (assuming we have some guard rails in place for my own liability).
Qualifications: Managing Partner at law firm heavily focused on this space. Actually in the business of advising DAOs and creating legal structures for them (not just theory).
Pros: Codifies things clearly Depending on method, limits liability to all participants Provides real world avenue for enforcement of rights
Cons: Involves meatspace may result in more rigidity than wanted (although I think that can probably be controlled for) Depending on method, even with my services pro bono there can be some unavoidable real world costs
Discussion in github. Issues should be prefixed with [Discussion], [Proposal], [Technical] or [Urgent]. I'm all for @nickbtts to organize the Github Issue Tracker a little more.
I'd be happy to help with cleaning the tracker up and tagging existing issues on an ongoing basis.
Thinking about ways to structure our Issues. This is specifically dealing with Step 1 from @nickbtts comment above.
At the moment, I see the following types of Issues being most useful to LobsterDao. [Discussion], [Proposal], [Technical or Implementation], [Question], [For Fun]
Additionally, I think using the following labels might make sense in order to cater to our contributors and issue readers. "Development", "Marketing", "Graphic Design", "Communications", "Perks".
I imagine the flow of issues could go from Question -> Discussion -> Proposal -> Implementation.
As Lobs spread across the digital ocean, there's likely to be greater discussion, more options, disparate opinion and the potential for disharmony.
A more rigid governance process would ensure that important issues are discussed, support sought and only the highest quality proposals are voted on. This is a discussion starter, rather than a solidified proposal. My thoughts on this:
Require an issue/proposal to be discussed and support gathered informally for a set period, or have a quorum of informal support. This may require migration to a more suited platform with poll facility (eg. commonwealth).
If majority support exists, move to a formal proposal with a standardised template (we could adopt something like a stripped down version of a Maker MIP)
Proposals submitted formally through a few nominated Governance facilitators. This keeps actual voting (snapshot) clean and with proposals that meet criteria and support.
Cheers!