This is a temporary document designed to provide a collection of initiatives of the early stages of AtomOne. Its purpose is multi-fold:
- Index of Activities: Catalog ongoing issues, discussions, and key themes as the project develops.
- Accessible Reference: Act as a central, accessible point of reference for all users.
- Initiative Tracking: Offer a simple framework for tracking and updating initiatives.
| Issue | Issue Creator | Summary |
|---|---|---|
| #7: Decentralists Party and AtomOne Hub Governance | jaekwon | Discussion on distinct governance for the Decentralists party and AtomOne hub. Suggestions for limiting Decentralists' control. |
| #8: Defining "Foster Diversity and Alignment" | moul | Need for a clear definition of fostering diversity and alignment. Emphasis on open dialogue among competing groups. |
| #10: Money as Tokenized Trust | irreverentsimplicity | Money as a medium of social cooperation and trust. Concept of soft forks and trust as primary value in monetary systems. |
| #12: ATOM vs ATONE Integration & Genesis Distribution | jaekwon | Strategic approach to integration and distribution between ATOM and ATONE. Models for effective integration. |
| #13: Include stATOM Holders in ATONE | asalzmann | Proposal to include stATOM holders in ATONE genesis or airdrop. Discussion on the treatment of stATOM holders. |
| #16: Fix Cosmos Hub Failures | COverS8 | Addressing centralization of voting power in Cosmos Hub. Proposal for snapshot and distribution for AtomOne airdrop. |
| #14: Brand Identity and Twitter Handle | wnmnsr | Discussion on the brand identity and @_atomone Twitter handle. Proposal for a new symbol representative of an atom. |
| #17: Choosing the Genesis Software Target | moul | Discussion on starting with Tendermint 2 or forking from Cosmos Hub 4. Trade-offs between early start and required work. |
| #18: Choose Snapshot Attributes | moul | Debate on specific block for snapshot. Consideration of other proposals beyond proposal 848. |
| #19: Fix Cosmos Ecosystem Power Dynamics | andergri | Reducing political complexities and promoting inclusivity in the Cosmos Ecosystem. Proposal of a primary chain to support all teams. |
| #21: ATOM-ONE Secure Communications for Users | COverS8 | Need for secure communication alternatives to Telegram and Discord. Proposal for a secure app for official governance communications. |
| #22: Link with Tendermint Atom One | moul | Questions about the connection between the AtomOne repository and Tendermint Atom One. Suggestions for a constitution and clarity on PHOTON design. |
| #23: Issues/PRs Moderation | moul | Challenge of selecting a responsible party for moderation. Proposal of an operations committee for moderation decisions. |
| #24: Setup Weekly Report | moul | Idea of initiating a weekly report. Use tools like ChatGPT to compile the list, with human intervention for fine-tuning. |
| #25: Should AiB Hire Dedicated Resources for Atomone? | moul | Proposal to create a job for overseeing AtomOne at AiB. Its role is to facilitate progress and act as a bridge between the community and AiB. |
| #26: Decentralists and Governance Structure | moul | Discussion on the role of Decentralists in AtomOne. Emphasis on defining their influence and control within the project's governance. |
| #27: Establishing and Monitoring Conditions for ICS | moul | Hardcoded conditions for becoming an ICS consumer. Discussion on governance approval, dApp virtualization, and financial commitments. |
| #29: Use GitHub Projects as a "Layer" System | moul | Proposal for using GitHub Projects for issue categorization. Suggesting Kanban-style labels and category tags. |
| #30: Create an Open Member List | moul | Establishing a list for interested contributors. Focusing on transparency and public engagement. |
| #31: Efficient Governance | qvuv05 | Discussing inflation rate reduction in ATOM and alternative governance models. |
| #32: Community Pool Financial Model | cryptulien | Proposing new funding approaches for the Community Pool. The suggestion of a linear financing model. |
| #33: Airdrops and Unstaking Emotional Impact | MasterFrenchie | Addressing emotional distress from halving, supporting creators, and considering KYC for distribution. |
| #36: Understand AtomOne | caillom | Metaphorical discussion to understand AtomOne's vision. A parallel is drawn between stranded community managing resources and AtomOne's governance. |
| #39: Limit AI/ChatGPT from AtomOne Core | jaekwon | Debate on the role and limitations of AI in AtomOne. Discussion on potential risks and benefits of AI integration in blockchain technology. |
| #40: Governance & Community Pool Thoughts | clockworkgr | Discussions on improving governance and community pool design in AtomOne. Suggestions include separating staking and governance and overhauling community pool funding. |
| #41: $PHOTON Token Design | giunatale | Delving into the design and functionality of the $PHOTON token. Topics include governance rights, auto-staking mechanisms, and tokenomics. |
| #44: Fund a Central Support Team for Chains on CosmosOne | tintin2828 | Proposal to fund a central support team for all chains launched on CosmosOne, specifically for routing IBC transactions. Discussing the potential of AtomOne Hub to route transactions and support new chains in its ecosystem. |
| #45: Governance Improvements | Ticojohnny | Discussion on various improvements to the governance system in AtomOne, focusing on representation and efficiency. |
| #50: META - High-Level Roadmap with DAGs | moul | Development of a high-level roadmap using DAGs as a structural framework for the AtomOne project. |
| #55: FAQ / AMA | moul | Creation of an FAQ/AMA forum for addressing community questions and concerns within the AtomOne project. |
| #58: ATOM Trade mark infringement | FarOutAndCosmic | Addressing the concerns of potential trademark infringement with the use of 'ATOM' in the context of Cosmos & blockchain. |
| #60: Internationalization | jaekwon | Initiative to translate AtomOne's documents into multiple languages, emphasizing human translation over AI. |
| #63: Choose the $ATOM1 ticker ($ATONE) | moul | Discussion and selection of the $ATOM1 ticker, with a temporary decision to use $ATONE. |
| #66: Define ICS1.5 | tbruyelle | Exploring the evolution and definition of Interchain Security (ICS) 1.5 within the AtomOne framework. |
| #70: Create an awesome-atomone / community repo | moul | Proposal to create a community-driven repository for AtomOne, including discussions, initiatives, recipes, and scripts. |
| #71: AtomOne GovNo (💩, governance-only) chain | jaekwon | Proposal for a governance-only chain, AtomOne GovNo, focused on sentiment assessment and governance discussion. |
| #72: How to Attract Aligned Individuals to a New Constitutional Hub | floridamanfintech | Discussion on strategies for attracting individuals aligned with AtomOne's ethos and principles to the new constitutional hub. |
| #74: Improving Delegators and Chain Safety | stevenoruzi | Addressing the safety of delegators in the Cosmos ecosystem and proposing solutions for better validator accountability and network security. |
| #75: Validators and KYC | jaekwon | Exploring KYC requirements and jurisdiction policies for validators in AtomOne. |
| #81: Liquid Staked ATONE | WaqarMMirza | Proposal to improve liquid staking in the AtomOne ecosystem by introducing multilevel Liquid Staking Tokens (LSTs) with a unified pool and universal recognition. |
| #83: AtomOne GovNo Community Townhalls | adrianakalpa | Planning and discussion of community townhalls for the GovNo chain, including agendas, member participation, and development updates. |
Issue #7 discusses the governance structures of the Decentralists party and the AtomOne hub.
- Distinction between Decentralists (democratic) and AtomOne (proof-of-stake).
- Decentralist involvement requires on-chain worth, not just token ownership.
- Proposals to cap Decentralists' control in AtomOne for balanced governance.
- Discussions about linking voting power to token ownership and stake duration.
- Suggestion for strict voting conditions and specialized Decentralist roles.
Issue #31 discusses the need for effective governance in AtomOne, using the example of proposal #848.
- Impact of proposal #848 on inflation and staking.
- Need for informed governance and alternative models.
Issue #39 proposes restricting AI, like ChatGPT, in AtomOne core.
- Concerns about AI in blockchain and limiting its use.
- Community feedback and voting on AI restrictions.
- Proposals for limited AI use and perspectives on AI use.
- AI as a tool vs. AGI as a potential threat.
Issue #40 discusses the improvement of governance and community pool design for AtomOne.
- Adopting Decentralists' DAO governance suggestions, separating stakeholder and governance.
- Proposal for stakers to delegate voting on proposals, potentially using a specific module.
- Introduction of a tagging system for proposals in different domains like marketing or architecture.
- Community pool overhaul suggestions, including limits on funding per proposal and denominating proposals in fiat equivalent.
- Gradual release of funds for proposals, with possible rescinding based on future approval.
Issue #45 addresses the need for improvements in AtomOne's governance system, emphasizing fair representation and efficiency.
- Discussion on preventing governance misuse for "griefing" and ensuring it represents the will of the common Atom One delegator.
- Proposals to lock voting rights to addresses staked at the beginning of each proposal and to restrict last-minute vote changes.
- Mandating public community hearings for new governance proposals and a minimum discussion period on public forums.
- Exploring better utilization of AtomOne delegators/voters in negotiations and proposal iterations.
- Strategies to minimize spam proposals and standardize community pool-funded operations.
- Suggestions for alternative validator power structures, including validators voting as per their delegator's majority.
- Debating voting limitations for "dust accounts" and recalibrating quorum requirements.
- Discussion on private voting and mission-specific funding organizations for more targeted governance.
- Concerns about validator influence overpowering individual votes.
- Ideas on restructuring voting power to better reflect the community's will.
- Potential systemic challenges with cryptocurrency governance and the need for future-proofing the governance model.
Issue #71 proposes the creation of a governance-only chain, AtomOne GovNo, as an independent component of genesis.
- AtomOne GovNo chain is proposed as a governance-focused chain, using a proposed token GOVNO solely for governance and staking.
- The chain would be a fork of cosmoshub4 with minimal modifications and SendTx disabled for GOVNO, emphasizing its non-monetary value.
- The primary purpose is to assess sentiments of No and NoWithVeto voters from proposition #848 and to discuss next steps for AtomOne.
- The chain would include a high deposit limit for proposals to prevent spamming and a consideration for slashing deposits if a proposal is heavily vetoed.
- Discussion on using a supermajority (⅔) for governance decisions and having proposals first discussed on GitHub.
- Consideration of different ways to evolve GOVNO over time, possibly through peer connections, meritocratic means, or standardized testing events.
- Suggestions to maintain a focus on sentiment assessment and avoid the potential for financial incentivization or misuse.
- Various community members expressed interest in participating in the process, coding, running validators, and voting.
- Discussions on the potential long-term evolution of the AtomOne GovNo chain, its naming, and the implications of its governance-only focus.
Issue #10 explores money as tokenized trust, examining its role in social cooperation and value perception.
- Money aligns varied perceptions of value, transitioning from a mental concept to a material, tokenized form.
- Tokenization simplifies value perceptions, facilitating social exchanges.
- Material representation of money can influence value perception.
- Collective trust in money's tokenized form impacts its value and community trust.
- Discussions include soft forking in financial ecosystems and trust's role in governance.
Issue #12 aims to address integrating ATOM and ATONE, focusing on distribution and slashing mechanisms for ATONE.
- Slashing in ATONE is necessary to enhance security decision-making intelligence.
- Debates on penalizing or rewarding ATOM holders based on proposal voting.
- Various methods for ATONE distribution and integration are considered.
- Trust and governance vulnerability in tokenized money reliance.
Issue #13 considers including stATOM holders in the ATONE genesis file or airdrop.
- Potential inclusion of stATOM holders in ATONE genesis or airdrop.
- Debate on the treatment of stATOM holders about governance participation.
- Distribution methods for ATONE to stATOM holders.
Issue #32 addresses the management of the Community Pool funds in the Cosmos ecosystem.
- Problems with current Community Pool management.
- Proposed focus areas for preserving and expanding the Community Pool.
- Governance and decision-making suggestions.
- Tax and reward structure considerations.
Issue #41 delves into the design and functionality of the $PHOTON token system.
- Discussion on PHOTON not providing governance rights, except for specific PHOTON-related proposals.
- Auto-staking of underlying ATONEs linked to PHOTON and challenges in rebalancing voting power.
- Proposal for a tax mechanism on auto-staked ATONEs and auto-compounding of underlying assets.
- The total supply cap for PHOTON is set at 1 Billion, with specific conversion formulae for bonding and unbonding.
- Examination of bonding dynamics, including incentives and impacts of slashing events.
- Need for defining a practical redemption mechanism for PHOTON, considering various dynamics of the dual-token model.
Issue #81 addresses the concept of liquid staking within the AtomOne ecosystem.
- Discussion on the current challenges of liquid staking in the Cosmos Hub, particularly in terms of governance voting power and validator selection.
- Proposal for a multilevel Liquid Staking Tokens (LSTs) system where each validator issues a unique LST, converging into a unified and universally recognized LST (stATONE).
- This system is intended to preserve the decentralization ethos of AtomOne while offering the benefits of liquid staking.
- Concerns raised about the potential governance takeover threat posed by liquid staking tokens with governance power.
- Suggestions to limit validator choices for liquid staking for security reasons and to address the Principal-Agent problem.
- Emphasis on the need for careful implementation to avoid governance issues.
- A suggestion to look at existing discussions on liquid staking in AtomOne, particularly in Issue #41 and the genesis README.
Issue #16 aims to adopt successful elements from the Cosmos Hub and address its shortcomings for AtomOne.
- Centralized voting power issues in the Cosmos Hub.
- Proposals for staking limits and validator identity disclosure.
- Assessment of validators' voting history in Cosmos Hub for AtomOne selection.
- Proposal for maximum staking limits with a single validator.
- Proposal for evaluating validators based on their voting history.
- Approach to airdrop mechanism, potentially excluding participants against AtomOne's vision.
- Learning from Cosmos Hub's tokenomics.
- Proposal for a community-driven treasury oversight committee.
Issue #17 discusses the initial software choice for AtomOne.
- Starting with Tendermint 2 (tm2) requires additional development.
- Starting with a Cosmos Hub 4 Fork allows for an early start but involves complex migration to tm2.
Issue #18 focuses on selecting the appropriate block for a snapshot in AtomOne.
- Debate on using specific blocks for the snapshot.
- Consideration of other proposals in snapshot attribute determination.
Link with Tendermint AtomOne Repository
Issue #22 seeks to clarify the relationship between AtomOne Hub's GitHub repository and the Tendermint repository.
- Discussion on the relationship between AtomOne Hub's and Tendermint's repositories.
- Need for a constitution and clarity on PHOTON design.
Issue #26 explores AtomOne's potential role as an ICS consumer.
- Debate on AtomOne being an ICS consumer.
- Alternatives and security considerations for ICS consumer status.
Issue #27 explores hardcoded conditions for AtomOne becoming an ICS consumer.
- Proposal for specific, hardcoded conditions for ICS consumers.
- Governance approval and virtualization of dApps discussed.
Issue #28 focuses on incorporating security standards into proposal evaluations for AtomOne.
- Proposals to include verifiable security standards, potentially marked by a 'security coverage' badge.
- Risk, security, and financial score integration for robust proposal assessment.
- Community-led review and feedback mechanism for proposals, with support for specialized security groups.
- Emphasis on balanced decision-making, combining strict security measures with adaptability for urgent proposals.
Issue #44 proposes the establishment of a central support team for all chains launching on CosmosOne and the Hub, with a focus on managing IBC transactions.
- The idea of a central support team to manage IBC transactions for all chains launched on CosmosOne.
- Potential for significant revenue generation through this initiative, which could be used for ecosystem growth, support, and user rewards.
- Discussion about AtomOne Hub's role in routing transactions and supporting new chains within its ecosystem.
- Consideration of AtomOne Hub as an alternative to using external relayers for transaction routing.
- Exploration of the possibility of AtomOne allowing new chains to launch and create their own ecosystem while connecting via IBC to the current Cosmos network and beyond.
Issue #66 discusses the evolution and potential definition of Interchain Security (ICS) 1.5 in the AtomOne context.
- Discussion about the different versions of main ICS protocols and the specific characteristics of ICS1.5.
- ICS1.5 as an evolution of Replicated Security, focusing on provider and consumer chain dynamics.
- Proposal to remove VCSMaturedPackets in ICS1.5 and the security implications of such a change.
- Consideration of two types of consumer chains in ICS1.5: "core shards" and "consumer shards", with core shards having a stronger link to the provider chain, particularly in governance.
- The need for further clarification on the differences between core and consumer shards.
- Potential other features of ICS1.5, including fast inter-hub communication with implied IBC without sacrificing independent BFT consensus layers.
- Community members provided insights on the complexity and security implications of proposed changes in ICS1.5.
- Discussions about the feasibility of implementing an "implicit" IBC for faster communication and shared validator sets.
- Suggestions that consumer and core shards might not require modifications to ICS but rather depend on how the consumer chain is designed.
Issue #74 discusses enhancing the safety and fairness for delegators and proposing measures for better validator accountability in the Cosmos ecosystem.
- Concerns about the impact of validator misconduct on delegators, especially those with minimal self-bonding.
- Suggestions for a variable minimum self-bond requirement or displaying self-bond amounts to inform delegators.
- Proposal to disallow the practice of creating new validators with the same name after one is jailed to prevent trust misuse.
- Idea of imposing a cap on the amount of bonded tokens per validator to prevent centralization and encourage a more diverse validator set.
- Consideration of automated undelegation processes for jailed validators to enhance staking security and fairness.
- Discussions on the potential of variable rewards systems to discourage centralization and incentivize validators to maintain a "Goldilocks Zone" for optimal reward earning.
- Debates on the practicality and fairness of various proposed solutions, such as self-bonding requirements and reward adjustments.
- Considerations for supporting new or small validators during the genesis phase and creating risk assessment tools for delegators.
- Discussions on the constitutionality and technical feasibility of implementing proposed measures for validator governance and delegator protection.
Issue #75 discusses the need for Know Your Customer (KYC) procedures for validators in the AtomOne ecosystem.
- Importance of KYC to ensure validator accountability and prevent Sybil attacks.
- Debate on the implementation of jurisdiction policy by validators and its subjectivity.
- Proposal for validators to self-declare their jurisdiction with a blockchain-based identifier.
- Discussion on the use of third-party identity verification services to confirm validators' jurisdiction.
- Suggestions for constitutional requirements for validators to provide accurate information, with potential penalties for misinformation.
- Consensus on starting with a permissionless base and supporting control experiments while preserving freedoms.
- Concerns about the subjective implementation of jurisdiction policies and potential biases in validator selection.
- Emphasis on the reputational stakes for validators in providing accurate jurisdiction information.
- Discussion on the simplicity and effectiveness of self-declaration and information transparency for delegators.
Issue #14 focuses on developing AtomOne's brand identity and Twitter handle (@_atomone).
- Proposal for AtomOne’s brand identity and Twitter handle reservation.
- Move towards natural element motifs, focusing on the Hydrogen molecule.
- Significance of Hydrogen in symbolizing fundamental properties.
- Design proposals with community feedback and development suggestions.
Issue #21 highlights the need for secure communication alternatives for AtomOne users.
- Need for end-to-end encrypted communication channels.
- An official, secure app or platform for governance communication is proposed.
Issue #58 raises concerns about the potential trademark infringement involving the use of 'ATOM' in the context of the Cosmos and blockchain ecosystem.
- Discussion on whether the use of 'ATOM' infringes on trademarks owned by the ICF in the context of Cosmos and blockchain.
- Debate on the distinction between 'AtomOne' and 'ATOM', and whether a rebranding might be necessary.
- Considerations about AtomOne's identity as a fork and how it should be reflected in its branding.
- Suggestions for different names and tickers, including 'Cosmos Hub Classic', 'Cosmos Classic', and '$GAIA', although some proposed tickers are already in use.
- Community feedback on various naming options, including '$ATONE'.
- Discussion on balancing the need for a distinctive identity with avoiding contention and confusion.
- Various perspectives on how to distinguish AtomOne's branding from existing trademarks.
Issue #63 focuses on choosing a suitable ticker for AtomOne, with an interim decision to use $ATONE.
- Initial update to try out $ATONE as the ticker for AtomOne.
- Discussion on the potential issue with the $ATOM1 ticker and links to relevant conversations.
- Suggestions to use $ATOM1 in documentation to emphasize concept explanation, with potential consideration for terms like $ATOMX as an equivalent to $phATOM1.
- Community suggestions for different tickers including $GAIA and the historical context of $ATONE, meaning "at one" or "united and reconciled".
- The decision to use $ATONE as a distinct identity, reflecting the spirit of AtomOne and its community.
- Discussions on the graphic identity of AtomOne and expanding the brand theme beyond just the chemical perspective of atomic structure.
- Various community members contributed to the discussion, suggesting different ticker names and supporting the use of $ATONE.
- Emphasis on creating a brand identity that is cohesive with the story and ethos of AtomOne.
Issue #19 addresses the power dynamics within the Cosmos Ecosystem.
- Need for a primary chain supporting all entities in Cosmos, reducing political complexity.
- Proposal for an inclusive and equitable ecosystem.
Issue #33 focuses on supporting users who unstaked ATOM due to recent proposals.
- Support for creators and Atom1 supporters who left the network.
- Concerns about governance direction and proposals.
- Challenges and solutions for rewarding supporters.
- Rewarding contributors and creators within the AtomOne ecosystem.
Issue #8 clarifies "fostering diversity and alignment" within the AtomOne and Decentralists framework. It emphasizes creating an ecosystem supporting diversity through self-aligned groups while maintaining alignment through shared values and goals.
- Diversity promotes competing and innovative ideas; alignment focuses on shared core values and principles.
- Distinction is needed between diversity in experimentation and alignment with the project’s constitution and principles.
- Clarity is essential in defining these concepts to prevent biased judgments and conflicting priorities.
Issue #30 discusses creating an open member list for AtomOne.
- Setting up a list of interested contributors.
- Mechanism for organization and participation.
- Proposed method for member listing.
- Importance of transparency and public engagement.
Issue #55 establishes a forum for the AtomOne community to ask questions, which will be addressed in a new FAQ.md file and possibly discussed in AMA (Ask Me Anything) sessions.
- Encouragement for community members to ask questions, regardless of whether they feel these questions merit their own issue.
- Selected questions will be replied to in a new FAQ.md file, and possibly discussed during AMA sessions.
- Reference to a related issue (#53) for additional context.
- Specific questions raised by community members, such as how to participate in meetings and details about snapshot dates or block heights for airdrops.
- Requests for guidance on how to engage with the project, including making pull requests and joining meetings.
- Queries about the snapshot date or block height and discussions on airdrop-related support for centralized exchanges (CEXs) like Binance, Coinbase, Upbit, etc.
- Direction to use specific issues, like #18 for snapshot-related questions.
Issue #70 discusses the idea of creating a community-driven repository for AtomOne.
- Proposal to create a repository similar to "awesome-gno" on GitHub, serving as a space for community-generated content and discussions.
- Potential repository names suggested include 'awesome-atomone' and 'awesome-atone'.
- The repository would include a disclaimer stating that the content is community-generated and unofficial.
- It would provide a platform for community discussions, initiatives, recipes, and scripts.
- Consideration of using the Wiki feature instead of PRs for maintaining news and summaries, making moderation more manageable.
- The repository could serve as a reference for new forks, important tweets, and other relevant information.
- Discussion on limiting AI usage to a specific section within the repository and setting boundaries for its use.
- Support for the idea of starting with an AWESOME.md file and observing how it evolves.
Issue #72 discusses strategies for attracting individuals who are aligned with the ethos and principles of AtomOne to the new constitutional hub.
- Focus on drawing in individuals both inside and outside the crypto space who align with AtomOne's vision of prioritizing security and hub minimalism.
- Addressing societal issues that led to distrust in current institutions as a way to connect with a broader audience.
- Proposing content creation that highlights problems created by existing systems, targeting a wider audience beyond crypto-natives and to encourage participation from non-technical members.
- Idea of creating a "political economy" within the AtomOne Hub, involving commerce of physical goods to engage the community in a new way.
- Suggestion to scale voting power in favor of delegators, reducing the influence of validators in governance decisions to enhance the sense of equality in participation.
- Discussions on how to make the AtomOne Hub appealing to a wider range of people, particularly those disillusioned with traditional institutions.
Issue #83 proposes a structure for community townhalls focused on the GovNo chain.
- Establishing a regular schedule for community townhalls to discuss GovNo chain developments.
- Preliminary agenda includes defining the GovNo chain, its governance token, governance structure, and its relationship with AtomOne.
- Discussion on the role of validators, members, and external contributors in the GovNo ecosystem.
- Addressing the process of self-organization and autonomy within the GovNo community.
- Providing updates on the technical development, validator onboarding, and current priorities of the GovNo chain.
- Planning for future community initiatives, prioritizing community concerns, and setting action items for subsequent meetings.
- Encouragement for community members to contribute topics or questions for the townhall agenda.
Issue #36 presents a metaphorical narrative to understand AtomOne.
- AtomOne compared to essential water and its inflation to a water source.
- Authority and regulation by the Decentralists.
- Inflation and tokenized trust implications.
- Alternative analogies and sustaining inflation.
Issue #23 discusses effective moderation of issues and PRs in AtomOne's GitHub repository.
- Debate on who should lead in moderating the GitHub repository.
- Proposed structures for moderation and the use of tools like ChatGPT.
Issue #24 proposes creating a weekly report for the AtomOne project.
- The report summarizes recent changes and assists in moderation.
- Methodology for report compilation with AI tools and human intervention.
Issue #25 discusses hiring a dedicated individual for AtomOne project management at AiB.
- Creating a position for overseeing the AtomOne project within AiB.
- Emphasis on transparency and community involvement.
Issue #29 discusses using GitHub Projects for categorizing issues in AtomOne.
- Categorization and labelling system proposals.
- Permission is required to create projects or assign issues.
- Suggestions for category tags and maintenance.
Issue #50 discusses creating a comprehensive high-level roadmap for AtomOne using Directed Acyclic Graphs (DAGs) to structure and visualize the development process.
- The aim to create and update high-level DAGs that can serve as indexes for navigating various topics within the project.
- Moderators with write permissions are tasked to keep top-level DAGs updated based on community suggestions.
- Outline of key milestones and tasks for AtomOne Phase 1 - Pre-IBC's Tasks.
- Items include defining the constitution, legal and licensing issues, governance and community engagement strategies, technical aspects and innovation, documentation and resources, recovery and compliance, and preparation for mainnet launch.
- Discussion on maintaining a single source of truth for the roadmap, with a suggestion to keep it in the README for better accessibility.
- The roadmap includes links to related issues and discussions, such as governance improvements and software targets.
Issue #60 addresses the need for translating AtomOne's documents into multiple languages, with a focus on human translation efforts.
- Proposal to start translating documents into other languages once the paragraph structure and known issues are settled.
- Storage of all translated documents in the repository, including the names of translators and the method of translation.
- Preference for human translation over AI to preserve the choice of terms and to grow community expertise.
- Encouragement for community members to contribute translations to naturally gauge interest and grow the decentralized localized community ecosystem.
- Community members volunteering to translate documents into Spanish, Persian, Italian, and French, with an emphasis on collaborative efforts.
- Suggestions for contracting human translators for languages where community volunteers are not available.