无网络连接
  1. Home
  2. Governance

DCIP-2: The Shamans Book [TASK DAO8] UNFINISHED...

作者:p1r0 @p1r0
    2023-07-27 23:36:53.499Z2023-07-28 13:49:21.178Z

    Simple Summary

    The Shamans are the highest level of participation in the DAO. DCIP-2 specifies their responsibilities.

    Abstract

    The proposal is an upgrade of the previews DCIP-2 which was based on the Decentralized Climate Foundation agile mandatory meetings. The Problems learned from the previews proof of concept which made the calls something casual and informal pushed out the need for a more formal way of organization based on the usage of a forum with templates for a DAO governance where this provides a scientific method based model on work proofs, consensus and referenced arguments.Lastly there is a fun work model based on a narrative and thus the name "The Shamans Book".

    Alt. abstract:
    The proposed upgrade, titled "The Shaman's Book", builds upon the previous DCIP-2 initiative, which leveraged the Decentralized Climate Foundation's agile mandatory meetings. Identified issues with the prior proof of concept, such as casual and informal communication, have highlighted the necessity for a more formal organizational approach. This upgrade introduces a forum and a DAO, fostering scientific-based models for work proofs, consensus, and referenced arguments. "The Shaman's Book" embraces a narrative-based, fun work model while addressing the need for greater structure and efficiency.

    Motivation

    One of the significant challenges with relying solely on phone calls for assigning and committing to responsibilities is the lack of formal documentation and accountability. When tasks and responsibilities are discussed verbally, there is a higher likelihood of team members avoiding or neglecting their duties because there is no concrete record or signed agreement to hold them accountable.

    Utilizing a forum for writing proposals and responsibilities, which are then subject to approval by a DAO, offers a more structured, transparent, and democratic approach to team decision-making compared to traditional phone calls. The written documentation ensures clarity and reduces ambiguity in task assignments, while the DAO's consensus-driven approval process fosters a sense of collective ownership and responsibility among team members. Additionally, the forum enables equal participation regardless of time zones and schedules, promoting inclusivity and diverse perspectives. Overall, this integrated approach empowers the organization to make well-informed decisions, enhance communication, and achieve greater efficiency in its operations.

    Specification

    The Shamans are responsible for verifying the tasks performed by the apprentices, writing new proposals and conducting symbolic rituals of thanks to Mother Earth (this can be tasks performed in the real world (AFK) an online community event, educational webinar, etc. .). The Shaman Requires a Magic Book to perform his tasks and responsibilities which is specified here. Each Shaman also has an associated animal species that symbolizes his specialization.

    The Specification section should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Decentralized Climate platforms.

    It is recommended to follow RFC 2119 and RFC 8170. Do not remove the key word definitions if RFC 2119 and RFC 8170 are followed.

    TODO: Remove this comment before submitting

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

    Rationale

    The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages.

    The current placeholder is acceptable for a draft.

    TODO: Remove this comment before submitting

    TBD

    Backwards Compatibility

    This section is optional.

    All DCIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The DCIP must explain how the author proposes to deal with these incompatibilities. DCIP submissions without a sufficient backwards compatibility treatise may be rejected outright.

    The current placeholder is acceptable for a draft.

    TODO: Remove this comment before submitting

    No backward compatibility issues found.

    Test Cases

    This section is optional for non-Core DCIPs.

    The Test Cases section should include expected input/output pairs, but may include a succinct set of executable tests. It should not include project build files. No new requirements may be be introduced here (meaning an implementation following only the Specification section should pass all tests here.)
    If the test suite is too large to reasonably be included inline, then consider adding it as one or more files in ../assets/dcip-####/. External links will not be allowed

    TODO: Remove this comment before submitting

    Reference Implementation

    This section is optional.

    The Reference Implementation section should include a minimal implementation that assists in understanding or implementing this specification. It should not include project build files. The reference implementation is not a replacement for the Specification section, and the proposal should still be understandable without it.
    If the reference implementation is too large to reasonably be included inline, then consider adding it as one or more files in ../assets/dcip-####/. External links will not be allowed.

    TODO: Remove this comment before submitting

    Security Considerations

    All DCIPs must contain a section that discusses the security implications/considerations relevant to the proposed change. Include information that might be important for security discussions, surfaces risks and can be used throughout the life cycle of the proposal. For example, include security-relevant design decisions, concerns, important discussions, implementation-specific guidance and pitfalls, an outline of threats and risks and how they are being addressed. DCIP submissions missing the "Security Considerations" section will be rejected. An DCIP cannot proceed to status "Final" without a Security Considerations discussion deemed sufficient by the reviewers.

    The current placeholder is acceptable for a draft.

    TODO: Remove this comment before submitting

    Needs discussion.

    History

    The Proposal is an extension from the DCF DAO Phase0 time measurements proposal to be implemented at the DCF DAO Phase1. There where DCF Agile mandatory meetings, but also some community request meetings and emergency or extra meetings online or even AFK at the foundation office. This proposal intends to Standarize the way meetings can be measured, which ones are mandatory and make them as more agile as possible.

    References

    1. David E. Perez Negron R. ( A.K.A p1r0), "DCIP2 IS BROKEN AND NEEDS AN UPGRADE.", Article: DCIP2 IS BROKEN AND NEEDS AN UPGRADE., 2023-07-20.

    Copyright

    Copyright and related rights waived via CC0.

    • 0 回复