{"id":676562,"date":"2025-04-26T06:57:57","date_gmt":"2025-04-26T06:57:57","guid":{"rendered":"https:\/\/gridnet.org\/wpp\/?p=676562"},"modified":"2025-04-26T08:26:20","modified_gmt":"2025-04-26T08:26:20","slug":"gridnet-basecamp-introduction","status":"publish","type":"post","link":"https:\/\/gridnet.org\/wpp\/index.php\/2025\/04\/26\/gridnet-basecamp-introduction\/","title":{"rendered":"GRIDNET Basecamp &#8211; Introduction"},"content":{"rendered":"<h2 class=\"text-xl font-bold text-text-100 mt-1 -mb-0.5\">Prologue: From Tribal Circles to Digital Loops<\/h2>\n<p>For almost the entirety of human existence, we have organized ourselves in circles. The earliest human tribes sat around fires in circular formations, sharing resources, stories, and tasks. Hunter-gatherers distributed duties based on skills and needs: some hunted, others gathered, some crafted tools, while others cared for children. This circular structure of contribution and distribution helped our species survive for hundreds of thousands of years.<\/p>\n<p>In the past 10,000 years, as complex civilizations emerged, we created hierarchies \u2013 pyramids of power that enabled coordination at unprecedented scales. Yet beneath these hierarchies, the essential circle of human cooperation persisted: one group produces what another needs, perpetuating cycles of interdependence that form the foundation of all human societies.<\/p>\n<p>Today, we stand at the threshold of a new evolution in human organization. Digital networks have already transformed how we cooperate and share resources. But most digital platforms remain centralized in structure \u2013 controlled by singular entities, much like the kingdoms and empires of old. GRIDNET presents a radical alternative: a return to the circle, but at a planetary scale and with capabilities our ancestors could never have imagined.<\/p>\n<h2>Building the Bridge to Decentralization<\/h2>\n<p>If anything, GRIDNET Basecamp represents an intermediate centralized step enabling our decentralized dreams to become REALITY. A place where we can cast spells\u2014TOGETHER.<\/p>\n<p>We, the Wizards, ensure financing for your projects as long as the Community finds your ideas sound and valid. Decentralized games? Applications? Decentralized social media platforms? As a developer, <strong>YOU ARE NO LONGER ALONE.<\/strong><\/p>\n<p>Gone is the need to file extensive documentation with banks for credit lines, or to negotiate with startup incubators, VCs, angel investors, and private equity firms\u2014only for them to lend you 10K USDT while claiming 80% of your business, treating you like assets to be traded for profit.<\/p>\n<p>Here, the process is beautifully simple:<\/p>\n<ul>\n<li>File for project incubation<\/li>\n<li>Wizards evaluate the technical feasibility<\/li>\n<li>Community validates the concept<\/li>\n<li>We ensure GRIDNET OS delivers what you need<\/li>\n<\/ul>\n<p>Take your ideas and your business wherever you want. We want you to grow. We want the world to be decentralized. Carry your freedom with you, and let your ideas benefit our entire Community. Grow together with us.<\/p>\n<p>What we care about most are innovative projects, expanded possibilities, and enhanced functionality sets. If you&#8217;re an open-minded person willing to make a difference\u2014even by creating an extraordinarily cool decentralized game\u2014you will feel at home here.<\/p>\n<p>Our Community will ensure you have the resources to make a living while building the decentralized future we all envision.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\" wp-image-676883 aligncenter\" src=\"https:\/\/gridnet.org\/wpp\/wp-content\/uploads\/2025\/04\/25.png\" alt=\"\" width=\"449\" height=\"674\" \/><\/p>\n<h2 class=\"text-xl font-bold text-text-100 mt-1 -mb-0.5\">Key Points<\/h2>\n<ul class=\"[&amp;:not(:last-child)_ul]:pb-1 [&amp;:not(:last-child)_ol]:pb-1 list-disc space-y-1.5 pl-7\">\n<li class=\"whitespace-normal break-words\">Wizards are not be be seen as ultimate decision makers. All decisions are taken by Community with Wizards acting as moderators. We transition towards full DAO based governance, with semi-automated on-chain decision making etc. Yet still no decentralised project on our planet exists as of now which would allow for the amount of data and agility required for versioning, online project editing, collaboration, tracking of financing etc. We ARE\u00a0 certainly getting there with GRIDNET OS (see the Whiteboard UI dApp, see the eMeeting UI dApp with state of the art group end-to-end encrypted audio\/video calls &#8211; BUT &#8211; we are not there yet for full fledged decentralised project management).\u00a0The NextCloud-based GRIDNET Basecamp is to be though of as a space shuttle bringing further building blocks to the decentralized orbit of GRIDNET OS.<\/li>\n<li class=\"whitespace-normal break-words\"><strong>Access:<\/strong> GRIDNET Basecamp is now available at <a class=\"underline\" href=\"https:\/\/team.gridnet.org\">https:\/\/team.gridnet.org<\/a><\/li>\n<li class=\"whitespace-normal break-words\"><strong>Account Security:<\/strong>\n<ul class=\"[&amp;:not(:last-child)_ul]:pb-1 [&amp;:not(:last-child)_ol]:pb-1 list-disc space-y-1.5 pl-7\">\n<li class=\"whitespace-normal break-words\">No email required for registration<\/li>\n<li class=\"whitespace-normal break-words\">If using email, create a dedicated account (e.g., Gmail sub-account)<\/li>\n<li class=\"whitespace-normal break-words\"><strong>Important:<\/strong> Email addresses are NOT considered private on this platform<\/li>\n<li class=\"whitespace-normal break-words\">Single Sign-On via Gmail is supported<\/li>\n<\/ul>\n<\/li>\n<li class=\"whitespace-normal break-words\"><strong>Purpose &amp; Function:<\/strong>\n<ul class=\"[&amp;:not(:last-child)_ul]:pb-1 [&amp;:not(:last-child)_ol]:pb-1 list-disc space-y-1.5 pl-7\">\n<li class=\"whitespace-normal break-words\">Serves as a bridge between centralized workflows and the decentralized GRIDNET OS<\/li>\n<li class=\"whitespace-normal break-words\">Facilitates collaboration between core team, third-party developers, and content creators<\/li>\n<li class=\"whitespace-normal break-words\">Enables structured project tracking, resource allocation, and community governance<\/li>\n<li class=\"whitespace-normal break-words\">Provides transparent accountability for GNC distribution and project financing<\/li>\n<\/ul>\n<\/li>\n<li class=\"whitespace-normal break-words\"><strong>Platform Capabilities:<\/strong>\n<ul class=\"[&amp;:not(:last-child)_ul]:pb-1 [&amp;:not(:last-child)_ol]:pb-1 list-disc space-y-1.5 pl-7\">\n<li class=\"whitespace-normal break-words\">Real-time collaboration on documents, including Microsoft Office formats (browser-based)<\/li>\n<li class=\"whitespace-normal break-words\">Integrated whiteboard functionality for visual collaboration<\/li>\n<li class=\"whitespace-normal break-words\">Group chats and video\/audio conferencing<\/li>\n<li class=\"whitespace-normal break-words\">Team management tools for organizing developers and contributors<\/li>\n<li class=\"whitespace-normal break-words\">Centralized repository for marketing assets accessible to influencers<\/li>\n<\/ul>\n<\/li>\n<li class=\"whitespace-normal break-words\"><strong>Opportunities:<\/strong>\n<ul class=\"[&amp;:not(:last-child)_ul]:pb-1 [&amp;:not(:last-child)_ol]:pb-1 list-disc space-y-1.5 pl-7\">\n<li class=\"whitespace-normal break-words\">Third parties can apply for financing of GRIDNET OS UI dApp development<\/li>\n<li class=\"whitespace-normal break-words\">Teams can establish their own managed workspaces within the platform<\/li>\n<li class=\"whitespace-normal break-words\">Content creators can participate in the Assets Request Board system<\/li>\n<\/ul>\n<\/li>\n<li class=\"whitespace-normal break-words\"><strong>Future Direction:<\/strong>\n<ul class=\"[&amp;:not(:last-child)_ul]:pb-1 [&amp;:not(:last-child)_ol]:pb-1 list-disc space-y-1.5 pl-7\">\n<li class=\"whitespace-normal break-words\">While built on battle-tested centralized technology (NextCloud), GRIDNET Basecamp is transitioning toward fully decentralized operation<\/li>\n<li class=\"whitespace-normal break-words\">The roadmap includes DAO-driven governance, decentralized voting, and automated GNC provisioning<\/li>\n<li class=\"whitespace-normal break-words\">Serves as a &#8220;space shuttle&#8221; delivering new functionalities to the decentralized GRIDNET OS ecosystem<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<h2>The Circular Community: Creators and Requesters<\/h2>\n<p>At the heart of GRIDNET lies a simple yet powerful principle: a circular relationship between community members. In any functioning ecosystem, different organisms fill different niches, creating a self-sustaining web of interactions. The GRIDNET community operates on a similar principle.<\/p>\n<p>Some members identify needs \u2013 educational content, explanatory graphics, technical tutorials \u2013 that would benefit the wider community. Others possess the skills to fulfill these needs. Rather than relying on central authorities to identify and commission necessary resources, GRIDNET enables direct cooperation through its Assets Request Board.<\/p>\n<p>This circular flow works as follows:<\/p>\n<ol>\n<li><strong>Community members and influencers<\/strong> identify needs and request specific content assets<\/li>\n<li><strong>Wizards<\/strong> (system developers and moderators) approve worthwhile requests and assign GNC value<\/li>\n<li><strong>Content Creators<\/strong> choose tasks that match their skills and passion<\/li>\n<li><strong>Completed assets<\/strong> return to the community, enhancing collective knowledge<\/li>\n<li><strong>GNC rewards<\/strong> flow to contributors, incentivizing future participation<\/li>\n<\/ol>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"size-full wp-image-676568 aligncenter\" src=\"https:\/\/gridnet.org\/wpp\/wp-content\/uploads\/2025\/04\/Screenshot-2025-04-25-at-21.22.20.png\" alt=\"\" width=\"482\" height=\"460\" \/><\/p>\n<p>Unlike traditional hierarchical organizations where value flows primarily upward, GRIDNET&#8217;s circular structure ensures that value continuously circulates throughout the community. This mimics natural ecosystems more than it does conventional human institutions \u2013 and perhaps this is why it feels simultaneously revolutionary and deeply familiar to us.<\/p>\n<h2>GRIDNET OS: The First Truly Decentralized Operating System<\/h2>\n<p>Throughout computing history, operating systems have followed the same pattern as political systems: centrally designed, centrally controlled, hierarchical in structure. From MS-DOS to Windows, from MacOS to Linux distributions, all operating systems \u2013 even open-source ones \u2013 ultimately require some form of central governance.<\/p>\n<p>GRIDNET OS represents the first genuine break from this pattern \u2013 the first truly decentralized operating system in human history. This is not merely a technical achievement but a conceptual leap comparable to the transition from monarchy to democracy, or from planned economies to market systems.<\/p>\n<p>What makes this possible now, when it wasn&#8217;t before? Just as writing enabled laws to exist independent of kings, and printing presses allowed knowledge to exist independent of churches, blockchain technology enables consensus to exist independent of central authorities. GRIDNET OS leverages this capability to create an operating environment where no single entity controls the system, yet order and functionality persist.<\/p>\n<p>The implications are profound. In the same way that democratic governance fundamentally transformed human political organization in the 18th-20th centuries, truly decentralized computing may reshape our digital existence in the 21st century and beyond.<\/p>\n<h2>Basecamp: The Bridge Between Two Worlds<\/h2>\n<p>Throughout history, revolutions rarely happen in a single, clean break with the past. The transition from one paradigm to another typically involves hybrid forms \u2013 bridges between what was and what will be. The American Revolution still incorporated English common law. Early democracies retained many aristocratic privileges. The first automobiles were called &#8220;horseless carriages&#8221; and designed to look like the vehicles they replaced.<\/p>\n<blockquote><p>GRIDNET Basecamp functions as precisely this kind of evolutionary bridge. While GRIDNET OS itself embodies full decentralization, Basecamp is an intermediate bridge between the two realms. It is a space shuttle launching new building blocks into the decentralized orbit of GRIDNET OS.<\/p><\/blockquote>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"size-full wp-image-676569 aligncenter\" src=\"https:\/\/gridnet.org\/wpp\/wp-content\/uploads\/2025\/04\/Screenshot-2025-04-25-at-21.23.01.png\" alt=\"\" width=\"1084\" height=\"339\" \/><\/p>\n<p>This hybrid approach serves several crucial functions:<\/p>\n<ol>\n<li>It enables teams to collaborate using familiar paradigms while building unfamiliar ones<\/li>\n<li>It provides a structured environment for tracking projects and coordinating efforts<\/li>\n<li>It facilitates real-time communication between team members<\/li>\n<li>It creates a centralized interface for external teams and projects to apply for funding<\/li>\n<li>It offers a controlled environment to develop and test functionality before decentralization<\/li>\n<\/ol>\n<p>Basecamp should not be seen as a contradiction of GRIDNET&#8217;s decentralized vision, but rather as a necessary evolutionary step toward it. Just as mammals once needed reptilian traits to evolve beyond them, new paradigms often require elements of the old to fully emerge.<\/p>\n<h2>The Wisdom of Wizards and Crowds: Collaborative Governance<\/h2>\n<p>Human governance has oscillated between two flawed extremes: rule by the few and rule by the many. Aristocracies and dictatorships concentrate wisdom but also concentrate corruption and self-interest. Pure democracies distribute power but can succumb to the tyranny of uninformed majorities.<\/p>\n<p>The most successful governance systems in history have found ways to balance these extremes \u2013 creating checks and balances that harness both the wisdom of experts and the collective judgment of communities.<\/p>\n<p>GRIDNET&#8217;s governance model embodies this balanced approach. The Wizards \u2013 developers and system architects with deep technical knowledge \u2013 work in partnership with the broader community. Neither group rules absolutely. Instead, they form a decision-making circle where specialized knowledge meets collective intelligence.<\/p>\n<p>On the Assets Request Board, this plays out in practical terms:<\/p>\n<ul>\n<li>Community members identify needs (harnessing distributed knowledge)<\/li>\n<li>Wizards evaluate, prioritize, and assign resources (applying specialized expertise)<\/li>\n<li>Content Creators contribute based on skills and interests (distributed execution)<\/li>\n<li>The community benefits from and evaluates the results (collective feedback)<\/li>\n<\/ul>\n<p>This approach recognizes that neither central planning nor pure crowd-sourcing alone can optimize complex systems. The future likely belongs not to fully decentralized or fully centralized models, but to thoughtfully designed hybrid systems that leverage the strengths of both approaches.<\/p>\n<h2>GNC: The Currency of Contribution<\/h2>\n<p>Money is perhaps humanity&#8217;s most successful fiction. For thousands of years, we have assigned value to objects with no intrinsic utility \u2013 shells, beads, metal discs, paper notes, and now, digital tokens. These tokens work because of shared belief in their value, enabling cooperation among strangers at unprecedented scales.<\/p>\n<p>Traditional currencies, however, remain tethered to nation-states and central banks \u2013 hierarchical entities that control money supply and policy. Cryptocurrencies introduced the possibility of currencies independent of central authority, but many simply replicated speculative market dynamics rather than serving specific community purposes.<\/p>\n<p>GNC assets represent something different \u2013 a currency intrinsic to a functional system, with value derived from actual contribution rather than speculation. Within GRIDNET, GNC serves as the lifeblood of the circular community relationship:<\/p>\n<ol>\n<li>GNC originates from the ICOFund domain\/account, managed by Wizards<\/li>\n<li>It flows to Content Creators who contribute valuable resources to the community<\/li>\n<li>These contributions enhance the GRIDNET ecosystem, increasing utility and adoption<\/li>\n<li>This increased utility strengthens the value proposition of the entire system<\/li>\n<li>The cycle continues as more value flows through the ecosystem<\/li>\n<\/ol>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"size-full wp-image-676570 aligncenter\" src=\"https:\/\/gridnet.org\/wpp\/wp-content\/uploads\/2025\/04\/Screenshot-2025-04-25-at-21.23.41.png\" alt=\"\" width=\"593\" height=\"484\" \/><\/p>\n<p>Unlike many cryptocurrencies that seek value primarily through scarcity and speculation, GNC derives value from its role in facilitating productive contribution. It is a currency backed not by gold or government decree, but by the tangible output of community members.<\/p>\n<h2>Join the Evolution: An Invitation<\/h2>\n<p>Throughout history, the most significant social and technological revolutions have begun with small groups of pioneers working at the margins before their innovations became mainstream. Democracy was once a radical experiment limited to ancient Athens. The internet began as a specialized academic network before transforming global communication.<\/p>\n<p>GRIDNET represents a similar pioneering effort \u2013 a community and technology at the forefront of what may become a fundamental shift in how humans organize digitally. By joining now, you become part of this evolutionary journey.<\/p>\n<p>The GRIDNET Basecamp platform is now available at https:\/\/team.gridnet.org. Here you can:<\/p>\n<ul>\n<li>Explore the Assets Request Board and see the circular community in action<\/li>\n<li>Apply to become a Content Creator and earn GNC rewards for your contributions<\/li>\n<li>Submit requests for content and resources that would benefit the community<\/li>\n<li>Connect with Wizards and other community members to collaborate on projects<\/li>\n<li>Help shape the transition toward fully decentralized applications on GRIDNET OS<\/li>\n<\/ul>\n<p>Whether you&#8217;re a developer, creator, visionary, or simply curious about decentralized futures, GRIDNET Basecamp offers an entry point into this emerging paradigm.<\/p>\n<h2>The Circle Completes<\/h2>\n<p>For 300,000 years, Homo sapiens organized in circles around fires, sharing tasks and resources within small, trusted groups. For 10,000 years, we built hierarchies that enabled coordination among strangers but concentrated power in the hands of the few. For 300 years, we&#8217;ve experimented with distributing power more broadly through democratic systems and markets.<\/p>\n<p>Now, digital technology enables us to combine the intimacy and trust of tribal circles with the scale and efficiency of modern systems. GRIDNET represents one of the boldest experiments in this new synthesis \u2013 a return to circular organization, but at unprecedented scale and with remarkable new capabilities.<\/p>\n<p>By joining this community, you&#8217;re not just adopting a new technology. You&#8217;re participating in the ongoing evolution of how humans cooperate and organize. The circle is completing \u2013 not by returning to the past, but by spiraling forward into new possibilities that our ancestors could scarcely have imagined.<\/p>\n<h2><\/h2>\n<h2>Assets Request Board for GRIDNET Basecamp<\/h2>\n<p>The\u00a0<strong>Assets Request Board<\/strong>\u00a0is a public Kanban-style board in GRIDNET&#8217;s Basecamp (Deck app) where community members and influencers can request new explanatory content assets (graphics, videos, tutorials, etc.). Approved\u00a0<strong>Content Creators<\/strong>\u00a0can then be assigned to produce these assets.\u00a0<strong>Wizards<\/strong>\u00a0(community moderators) oversee this board \u2013 they approve requests, assign tasks to creators, and ensure each request moves through stages from initial idea to final delivery and GNC reward payment. This unified board simplifies the content creation process, providing transparency and a clear structure for everyone involved.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"size-full wp-image-676568 aligncenter\" src=\"https:\/\/gridnet.org\/wpp\/wp-content\/uploads\/2025\/04\/Screenshot-2025-04-25-at-21.22.20.png\" alt=\"\" width=\"482\" height=\"460\" \/><\/p>\n<h2>Board Columns and Asset Lifecycle<\/h2>\n<p>The board is organized into several columns (lists), each representing a stage in the lifecycle of an asset request. Only Wizards can move cards between columns, ensuring that each stage is properly managed. The columns on the Assets Request Board are:<\/p>\n<ol>\n<li><strong>New Request (Submitted)<\/strong>\u00a0\u2013 Newly submitted asset requests from community members or influencers appear here. Each card in this column represents a content idea awaiting review. The card includes details of what content is needed (using the template provided). Wizards monitor this list and review each request in turn.<\/li>\n<li><strong>Approved (Open for Assignment)<\/strong>\u00a0\u2013 Once our team reviews a request and deems it appropriate (feasible, non-duplicate, aligned with community goals), the card is moved to\u00a0<strong>Approved<\/strong>. In this column, the request is officially accepted. Wizards will typically update the card with a confirmed\u00a0<strong>reward amount (in GNC)<\/strong>\u00a0and any additional notes or requirements. The task is now open to be assigned to an approved Content Creator. (At this stage, Wizards may either wait for a Content Creator to volunteer via comments or proactively assign one.)<\/li>\n<li><strong>Assigned &amp; In Progress<\/strong>\u00a0\u2013 When\u00a0our team assigns an approved request to a specific Content Creator, the card moves into\u00a0<strong>Assigned &amp; In Progress<\/strong>. The Content Creator\u2019s name is noted on the card, along with a due date if applicable. In this column, the asset is actively being created. The Content Creator works on the graphic\/video\/tutorial and posts updates or questions in the card\u2019s comments. The requester and Wizards can also chime in to clarify details as needed. This stage is all about execution and iteration.<\/li>\n<li><strong>Ready for Review (Content Delivered)<\/strong>\u00a0\u2013 Once the Content Creator finishes the asset, they attach the content or provide a link in the card and notify the Wizards (via a comment) that it&#8217;s ready. The card then moves to\u00a0<strong>Ready for Review<\/strong>. Wizards (and possibly the original requester, if needed) will review the delivered content here. They check that it meets the requirements, is accurate, and follows any style guidelines. If changes are required, the card remains in this column while the Content Creator makes revisions (with the status updated in the card\/comments).<\/li>\n<li><strong>Completed (Delivered &amp; Paid)<\/strong>\u00a0\u2013 After the content passes review and is approved by a Wizard, the task is marked completed and the card moves to\u00a0<strong>Completed<\/strong>. At this final stage, Wizards arrange for the reward payment in\u00a0<strong>GNC<\/strong>\u00a0to the Content Creator as promised. The card\u2019s description or comments should be updated with a final note (e.g., confirmation of delivery and payment). Completed tasks remain visible here as a record of fulfilled requests and as a reference library of created assets.<\/li>\n<\/ol>\n<p><em>(Optional: There can be an additional\u00a0<strong>Closed\/Rejected<\/strong>\u00a0column for requests that do not get approved. For example, if a request is a duplicate, inappropriate, or not feasible, Wizards can move the card to &#8220;Closed&#8221; with an explanation in the comments. This keeps the &#8220;New Request&#8221; column clean while providing transparency about why certain requests did not proceed.)<\/em><\/p>\n<p>Each column is publicly viewable so community members can track the progress of their requests in real time. Because only Wizards have permission to move cards, the workflow remains orderly \u2013 community requesters submit ideas, Content Creators focus on execution, and Wizards handle the stage transitions.<\/p>\n<h2>Card Templates for Each Stage<\/h2>\n<p>To ensure consistency, each card on the Assets Request Board should follow a template that is updated as it progresses through the stages. Below are recommended card content templates for each stage of the process. When creating or updating a card, copy the relevant template sections into the card\u2019s description and fill in the details.<\/p>\n<ul>\n<li><strong>New Request (Submission Stage) \u2013 Card Template:<\/strong>When a community member or influencer creates a new request, they should format the card as follows:\n<pre>Asset Title: [A short, descriptive title for the requested asset]\r\n\r\nDescription\/Purpose: [A detailed description of what the asset should cover or achieve. Include the topic, key points to explain, and why this content is needed.]\r\n\r\nAsset Type: [Graphic \/ Video \/ Article \/ Tutorial \/ Other \u2013 specify the format of content being requested]\r\n\r\nTarget Audience: [e.g., Beginner, Advanced, General Audience \u2013 who is this content aimed at?]\r\n\r\nLanguage: [Preferred language for the content, e.g., English, Polish, Spanish]\r\n\r\nAdditional Requirements: [Any specific requirements or preferences \u2013 e.g., length\/duration, image dimensions, style or branding guidelines, platform where it will be used]\r\n\r\nRequester: [Your name or handle, if not automatically noted on the card]\r\n\r\nReferences\/Links: [Optional \u2013 links to relevant materials or examples for inspiration]\r\n<\/pre>\n<p>The requester should fill in all applicable fields. The card\u2019s title should be concise (e.g., &#8220;Tutorial: Setting Up a Node on GRIDNET&#8221;) and the description should clearly outline expectations. Providing thorough info at this stage helps Wizards and Content Creators understand the request.<\/li>\n<li><strong>Approved (Post-Review Stage) \u2013 Card Template Update:<\/strong>Once a Wizard moves the card to &#8220;Approved,&#8221; they will augment the card with additional fields for assignment and reward:\n<pre>Status: \u2705 Approved by on [Date]. (Ready for assignment to a Content Creator)\r\n\r\nReward: [X] GNC (to be paid upon completion)\r\n\r\nPriority: [High \/ Medium \/ Low] (optional, if applicable based on urgency or importance)\r\n\r\nAssigned Content Creator: [To be determined or @Name once assigned]\r\n<\/pre>\n<p>In this stage, the Wizards make it clear that the task is approved and what the incentives are. The &#8220;Assigned Content Creator&#8221; can remain &#8220;To be determined&#8221; at first. Wizards may add a comment calling for volunteers or indicating that they are seeking an assignee.<\/li>\n<li><strong>Assigned &amp; In Progress \u2013 Card Template Update:<\/strong>When a task is assigned, Wizards (or the Content Creator) should update the card description to reflect the current status:\n<pre>Status: \ud83d\udea7 In Progress \u2013 Assigned to [Content Creator Name] on [Date].\r\n\r\nAssigned Content Creator: [Name (@username)]\r\n\r\nDeadline: [Date or timeframe for completion, if set]\r\n\r\nCurrent Progress: [Optional \u2013 brief notes on progress, e.g., \"Outline drafted\", \"50% complete\", \"Awaiting feedback on script\"]\r\n<\/pre>\n<p>The Content Creator can also add a checklist or sub-tasks in the card (e.g., &#8220;Storyboard&#8221;, &#8220;Draft version&#8221;, &#8220;Review edits&#8221;, &#8220;Final production&#8221;) to track work internally. Throughout this stage, the card\u2019s comments serve as the primary communication channel for updates, questions, and clarifications.<\/li>\n<li><strong>Ready for Review \u2013 Card Template Update:<\/strong>When the content is finished and uploaded, update the card as follows:\n<pre>Status: \ud83d\udccb Ready for Review \u2013 Content submitted on [Date].\r\n\r\nDeliverables: [Link or attachment to the completed asset. For example: \"See attached video file\", \"Image uploaded above\", or \"Draft article: link to Google Doc\"]\r\n\r\nNotes for Review: [Any notes from the creator about the submission, e.g., \"Please check audio at 2:00 for volume\", \"Colors can be adjusted if needed\", or \"Alternate version in second attachment\".]\r\n<\/pre>\n<p>The Wizard(s) reviewing will use the comments to give feedback or approval. If revisions are needed, the card stays in this column; the Content Creator should address the feedback and update the deliverables, then comment again to notify Wizards for another review round.<\/li>\n<li><strong>Completed \u2013 Card Template Update:<\/strong>After final approval, the card should be updated to record completion:\n<pre>Status: \ud83c\udf89 Completed \u2013 Approved  on [Date].\r\n\r\nOutcome: [Summary of the final outcome, e.g., \"Infographic published on Twitter and community wiki\", or \"Video uploaded to official YouTube channel\".]\r\n\r\nReward Payment: [X] GNC transferred to [Content Creator Name] on [Date]. (Transaction reference: [Optional TX ID or confirmation if applicable])\r\n\r\nAcknowledgements: [Optional \u2013 e.g., \"Thanks to [Content Creator] for the great work on this asset!\" and\/or \"Requested by [Requester Name]\".]\r\n<\/pre>\n<p>Wizards should ensure the reward payment details are recorded for transparency. After this, the task is considered closed. The card remains in the Completed column as a public record and for future reference (others can see the asset or find it via tags).<\/li>\n<\/ul>\n<p>Using these templates at each stage ensures anyone viewing the card can quickly understand its history and current status. The structured format helps Wizards, Requesters, and Content Creators stay aligned and not miss important information.<\/p>\n<h2>Guidelines for Requesters (Community Members &amp; Influencers)<\/h2>\n<p>Community members and influencers who want to request content should follow these guidelines to make the process smooth and successful:<\/p>\n<ul>\n<li><strong>Search Before Requesting:<\/strong>\u00a0Before creating a new request, check the board (especially the Completed column or any existing asset library) to see if a similar asset already exists or is in progress. This avoids duplicate requests and shows you what\u2019s already available.<\/li>\n<li><strong>Use the Template:<\/strong>\u00a0When submitting a request, use the\u00a0<strong>New Request<\/strong>\u00a0card template provided above. Provide a clear title and a thorough description. The more details you give, the easier it is for Content Creators to deliver exactly what you need. Incomplete requests might be delayed while Wizards seek clarification.<\/li>\n<li><strong>Specify Audience and Purpose:<\/strong>\u00a0Clearly state who the content is for and what you want to achieve. For example, &#8220;This video is for beginner users who need help setting up a wallet&#8221; or &#8220;This graphic will be used in social media to explain our project.&#8221; This context helps creators tailor the content appropriately in tone and depth.\n<ul>\n<li><strong>Provide a clear title and a thorough description.<\/strong> The more details you give, the easier it is for Content Creators to deliver exactly what you need. Incomplete requests might be delayed while Wizards seek clarification.<\/li>\n<li><strong>Specify Audience and Purpose:<\/strong> Clearly state who the content is for and what you want to achieve. For example, &#8220;This video is for beginner users who need help setting up a wallet&#8221; or &#8220;This graphic will be used in social media to explain our project.&#8221; This context helps creators tailor the content appropriately in tone and depth.<\/li>\n<li><strong>Tag Your Request:<\/strong> Apply relevant <strong>tags\/labels<\/strong> to your card if possible. For example, tag the asset type (<strong>Graphic<\/strong>, <strong>Video<\/strong>, <strong>Tutorial<\/strong>), the difficulty level (<strong>Beginner<\/strong> or <strong>Advanced<\/strong>), and the language. Proper tagging ensures your request is categorized correctly and can be filtered easily by others. If you&#8217;re not sure about tags, Wizards will adjust them, but it&#8217;s helpful if you add what you can.<\/li>\n<li><strong>Be Responsive to Questions:<\/strong> After submitting, keep an eye on your request card. Wizards might ask clarifying questions in the comments or suggest changes to your description. Respond promptly to keep the process moving.<\/li>\n<\/ul>\n<\/li>\n<li><strong>Be Responsive to Questions:<\/strong>\u00a0After submitting, keep an eye on your request card. Wizards might ask clarifying questions in the comments or suggest changes to your description. Respond promptly to any questions or requests for info \u2013 this helps move your request to the Approved stage faster. If you disappear, your request might stagnate or be closed due to lack of info.<\/li>\n<li><strong>Stay Informed (but Patient):<\/strong>\u00a0Once your request is approved, understand that it may take some time to be assigned and completed. You can watch as it moves through the columns. It\u2019s okay to ask for status updates politely (for instance, if it&#8217;s been quiet for much longer than usual), but keep in mind Content Creators may be balancing tasks. Wizards will ensure nothing is forgotten.<\/li>\n<li><strong>Engage During Review:<\/strong>\u00a0If you\u2019re the requester, you might be tagged when the content is ready for review, especially if your input is needed to verify that it meets your needs. Provide feedback if you have any (e.g., &#8220;This covers everything I wanted, thanks!&#8221; or &#8220;It\u2019s great, but can we also mention X?&#8221;). Your perspective is valuable, but also trust the Content Creator and Wizards\u2019 expertise on quality and style.<\/li>\n<li><strong>Express Gratitude and Feedback:<\/strong>\u00a0After completion, if you found the asset useful, do thank the Content Creator and Wizards in the card comments. If you have suggestions for improvement, you can mention them as well (constructively). Positive feedback motivates creators, and constructive feedback can help in future tasks.<\/li>\n<\/ul>\n<p>By following these guidelines, requesters help ensure their ideas are understood and acted on efficiently. A well-prepared request with active requester participation is more likely to result in a high-quality asset that meets the need.<\/p>\n<h2>Guidelines for Content Creators<\/h2>\n<p>Approved Content Creators are community members who have applied and been authorized to create official content assets. If you are a Content Creator working on this board, please keep the following guidelines in mind to collaborate effectively:<\/p>\n<ul>\n<li><strong>Review Available Tasks:<\/strong>\u00a0Regularly check the\u00a0<strong>Approved (Open for Assignment)<\/strong>\u00a0column for new requests that match your skill set (e.g., graphic design, video editing, technical writing). If you see a request you\u2019d like to work on, leave a comment on that card expressing interest. For example: &#8220;I can take this on, I have experience with infographic design. @WizardName&#8221;. This lets Wizards know you&#8217;re available. (If multiple creators volunteer, a\u00a0we will decide who to assign, so don\u2019t be discouraged if not every volunteer opportunity is assigned to you.)<\/li>\n<li><strong>Wait for Official Assignment:<\/strong>\u00a0Only start working on a task\u00a0<strong>after we<\/strong>\u00a0assign it to you and moves the card to In Progress with your name. This prevents confusion or duplicate work. Wizards may confirm assignment by tagging you in a comment like &#8220;Assigned to @YourName&#8221; and updating the card. If you commented to volunteer and haven\u2019t heard back yet, you can follow up after some time or look for another task in the meantime.<\/li>\n<li><strong>Clarify Requirements Up Front:<\/strong>\u00a0As soon as you\u2019re assigned, review the entire card (description and prior comments) carefully. If anything is unclear or if you need additional resources (logos, data, access, etc.), ask in the card comments. It\u2019s better to gather clarity at the start than to redo work later. Tag the requester or Wizards as needed for specific questions.<\/li>\n<li><strong>Use the Card to Track Work:<\/strong>\u00a0Follow the\u00a0<strong>In Progress<\/strong>\u00a0template by updating the card description with your name and the start date, and note any deadline. Feel free to add a checklist of sub-tasks on the card (Deck allows adding checklist items). Checking off items (like &#8220;script written&#8221;, &#8220;voiceover recorded&#8221;, &#8220;first draft complete&#8221;) not only helps you stay on track but also lets Wizards and the requester see progress at a glance. You can also post periodic short updates in comments, especially for longer tasks (e.g., &#8220;Drafting completed, moving on to recording audio&#8221;).<\/li>\n<li><strong>Maintain Quality and Branding:<\/strong>\u00a0Ensure the content you produce meets the community\u2019s quality standards and branding. Follow any style guides provided. For example, use official logos and correct color schemes for graphics, maintain accuracy and clarity in tutorials, and ensure good production values in videos (clear audio, proper resolution). If no formal guide exists, look at similar past assets in the Completed column as a reference for the expected tone and quality.<\/li>\n<li><strong>Time Management:<\/strong>\u00a0Honor the deadlines given. If a card has a due date or is tagged<br \/>\nUrgent, prioritize accordingly. If no deadline is explicit, use reasonable judgment (Wizards might give guidance like &#8220;hope to have this in about 2 weeks&#8221;). If you encounter delays (personal issues, unexpected complexity, etc.), inform us\u00a0<strong>before<\/strong>\u00a0the deadline passes. They can possibly extend the deadline or find additional help. Communication is key \u2013 it\u2019s understood that delays can happen, but keeping silent is not okay.<\/li>\n<li><strong>Submit Work for Review:<\/strong>\u00a0When you finish the asset, attach the file(s) to the card or provide a stable link. For large files, you might use a cloud storage link or a specialized platform (e.g., upload a video to an unlisted YouTube link for preview). Ensure the\u00a0<strong>Deliverables<\/strong>\u00a0section in the card description is filled out with where to find the content. Then add a comment tagging the relevant Wizard(s) and requester: e.g., &#8220;@WizardName @RequesterName The video is ready for review, please check the link above.&#8221; After this, move on to other work while waiting \u2013 do not mark the card complete yourself.<\/li>\n<li><strong>Handle Feedback Gracefully:<\/strong>\u00a0It&#8217;s common to receive some feedback or requests for edits. Check the card comments after submission. If Wizards\/requester suggest changes, acknowledge the feedback and make the revisions as needed. Use the\u00a0<strong>Notes for Review<\/strong>\u00a0field or follow-up comments to describe what you changed or address any concerns. For example, &#8220;I&#8217;ve increased the font size on the infographic for readability, and corrected the stats in section 2.&#8221; Re-submit the updated content promptly. Remember, feedback isn\u2019t personal criticism \u2013 it\u2019s to ensure the final asset is the best it can be.<\/li>\n<li><strong>Completion and Reward:<\/strong>\u00a0Once we approve the content and moves the card to Completed, your job on that card is done! We will handle the GNC reward payment. Make sure you have provided your wallet\/address to them beforehand (probably during your application or via a profile). The card will note that you were paid. If there\u2019s any discrepancy (e.g., you haven&#8217;t received payment after a reasonable time), reach out to us directly (you can use Talk for a private message if needed and contact Wizards account). Typically, though, this process is smooth: you create great content, the community benefits, and you earn your reward.<\/li>\n<li><strong>Continuous Improvement:<\/strong>\u00a0As an approved Content Creator, you are a part of the GRIDNET content team. Feel free to share tips with fellow creators, ask for help if stuck, or suggest improvements to these processes. You might use a separate forum or group chat for creators to discuss things outside specific request cards. Wizards will appreciate suggestions that can streamline the workflow or address common issues. Also, maintain a good record \u2013 reliable and high-quality work might lead to more frequent assignments or even higher rewards over time.<\/li>\n<\/ul>\n<p>By following these guidelines, Content Creators can effectively contribute to the community, build a portfolio of work, and earn GNC rewards. The key is communication, quality, and collaboration at each step of the process.<\/p>\n<h2>Process for Applying to Be a Content Creator<\/h2>\n<p>Community members who want to become approved Content Creators (so they can be assigned tasks on this board) need to go through an application process. This ensures that creators have the necessary skills and understand GRIDNET\u2019s content standards. Here\u2019s how to apply:<\/p>\n<ol>\n<li><strong>Visit the Content Creator Application Board:<\/strong>\u00a0GRIDNET Basecamp provides a separate Deck board for creator applications. (This could be linked from the Assets Request Board or mentioned in community docs \u2013 e.g., an &#8220;Apply to be a Content Creator&#8221; link.) On that Application Board, you&#8217;ll find instructions and an application card template.<\/li>\n<li><strong>Submit Your Application Card:<\/strong>\u00a0Create a new card in the Application board, filling out the required details. Typically, include:\n<ul>\n<li><strong>Name and Contact:<\/strong>\u00a0Who you are and how to reach you (your Basecamp username, email, or other contact info).<\/li>\n<li><strong>Skills and Content Areas:<\/strong>\u00a0Describe what kind of content you can create. Mention your specialties (e.g., &#8220;infographic design&#8221;, &#8220;animated videos&#8221;, &#8220;technical writing&#8221;) and any specific domain knowledge (e.g., &#8220;familiar with blockchain and DeFi concepts&#8221;).<\/li>\n<li><strong>Experience and Portfolio:<\/strong>\u00a0List any relevant experience or qualifications. Provide links to examples of your work if available (e.g., a portfolio, previous graphics or videos, blog posts\/tutorials you&#8217;ve written, etc.). If you have contributed to other community projects or open-source efforts, mention those too.<\/li>\n<li><strong>Availability:<\/strong>\u00a0Note how much time you expect to dedicate (for instance, &#8220;5-10 hours per week&#8221; or &#8220;mostly weekends&#8221;) and any schedule constraints. This helps Wizards know what scope of tasks to assign.<\/li>\n<li><strong>Motivation:<\/strong>\u00a0A brief statement on why you want to be a content creator for GRIDNET. Enthusiasm and alignment with the community\u2019s mission can help your application.<\/li>\n<li><strong>GNC Wallet Address:<\/strong>\u00a0(If applicable at this stage) Provide the address where you would like to receive rewards. If security is a concern, you could optionally provide this after acceptance via a secure channel instead of on the public card.<\/li>\n<\/ul>\n<\/li>\n<li><strong>Wizards&#8217; Review of Application:<\/strong>\u00a0Wizards will monitor the Application Board and review new submissions. They may leave comments on your application card with questions or requests for clarification. For example, they might ask to see a specific type of work sample or inquire about your knowledge of a topic. Engage with these questions promptly and thoroughly.<\/li>\n<li><strong>Approval &amp; Onboarding:<\/strong>\u00a0If your application is approved, Wizards will move your card to an &#8220;Approved&#8221; or similar column on the Application Board (or otherwise indicate acceptance). We will likely reach out with a welcome message. You will be granted the &#8220;Content Creator&#8221; role or added to the list of approved creators. This may include giving you certain permissions on the Basecamp (Deck) boards (like the ability to comment on the Assets Request Board cards and access any private creator resources). They might also invite you to a communication channel for Content Creators (for example, a Talk chat room or a forum thread for creators).<\/li>\n<li><strong>Orientation:<\/strong>\u00a0Upon approval, you might receive onboarding materials. This could be a guide with best practices, branding assets (logos, design templates), and references to past exemplary content. You might even be asked to start with a small test task or contribute to a simple request to get familiar with the process. Take time to review any guidelines provided \u2013 this sets you up for success in handling real requests.<\/li>\n<li><strong>Start Taking Tasks:<\/strong>\u00a0After onboarding, you can start picking up tasks from the Assets Request Board as described in the creators\u2019 guidelines. You now have the green light to volunteer for requests in the Approved column. Make sure to always follow the board process even though you\u2019re now an official creator.<\/li>\n<li><strong>Ongoing Evaluation:<\/strong>\u00a0Note that being an approved Content Creator is an ongoing role. Wizards may periodically review creators\u2019 performance. Consistently good work means you remain in good standing (and might get perks or higher-value assignments). If someone repeatedly fails to deliver or violates guidelines, Wizards might remove them from the creator list. This is rare and avoided by selecting good applicants and giving feedback, but it&#8217;s part of maintaining quality.<\/li>\n<\/ol>\n<p>By following this application process, the community ensures that those who produce content have demonstrated their ability and commitment. For applicants, it\u2019s a chance to show your passion and skills. Once on the team, you become a crucial part of educating and growing the GRIDNET community while earning rewards for your contributions.<\/p>\n<h2>Roles and Responsibilities of Wizards<\/h2>\n<p>Wizards act as facilitators and gatekeepers on the Assets Request Board. They have special permissions and responsibilities to ensure the system runs smoothly and fairly:<\/p>\n<ul>\n<li><strong>Moderating New Requests:<\/strong>\u00a0Wizards regularly monitor the\u00a0<strong>New Request<\/strong>\u00a0column. For each incoming request, they verify that it\u2019s clear, relevant to the community, and not a duplicate of existing content. If a request is unclear or missing information, we will comment to ask the requester for clarification or additional details (and may @mention the requester to get their attention). They might also make minor edits to the card (formatting, tagging) to ensure it fits the template and standards.<\/li>\n<li><strong>Approval or Rejection Decisions:<\/strong>\u00a0Wizards decide which requests get approved. Criteria may include usefulness to the community, alignment with current goals or topics of interest, and feasibility (do we have creators with the necessary skills\/time?). If approved, a wizard moves the card to the Approved column, and updates the card with the reward amount and any notes. If a request is rejected or put on hold, one of us moves it to\u00a0<strong>Closed\/Rejected<\/strong>\u00a0(or leaves it in New Request with an explanatory comment) and provides a polite explanation. For example: &#8220;Rejected \u2013 a similar tutorial already exists&#8221; or &#8220;On hold \u2013 awaiting more details from requester.&#8221;<\/li>\n<li><strong>Setting Reward Amounts:<\/strong>\u00a0For each approved request, Wizards determine an appropriate\u00a0<strong>reward in GNC<\/strong>\u00a0for the task, based on its complexity and the effort required. They should be fair and perhaps follow a guideline or budget. (For instance, a simple graphic might have a smaller reward than a full video tutorial.) The reward is clearly noted on the card so that any potential Content Creator knows the incentive upfront. All rewards are paid only after successful completion and approval of the content.<\/li>\n<li><strong>Assigning Tasks to Creators:<\/strong>\u00a0Wizards oversee the assignment of tasks to Content Creators. They ensure that only\u00a0<strong>approved Content Creators<\/strong>\u00a0take on tasks. When a creator volunteers for a task via a comment, a\u00a0wizard\u00a0will typically confirm by assigning that creator: they might reply &#8220;Okay, @CreatorName you\u2019ve got it,&#8221; then\u00a0<em>move the card to In Progress<\/em>\u00a0and update the &#8220;Assigned Content Creator&#8221; field. If multiple creators offer, Wizards decide who to assign \u2013 they might consider the first volunteer, or choose based on expertise or current workload. (Wizards aim to be fair and transparent in these choices, possibly explaining in a comment like &#8220;Assigning to @Alice as she has relevant design experience. @Bob, we\u2019ll have more tasks coming up!&#8221;). Sometimes, for high-priority tasks, Wizards might directly approach a specific creator they know is best suited or available.<\/li>\n<li><strong>Supervising Work in Progress:<\/strong>\u00a0While content is being created, Wizards keep an eye on the\u00a0<strong>Assigned &amp; In Progress<\/strong>\u00a0column. They check that progress updates are coming in and intervene if a card seems stalled. If a deadline is looming or past, a Wizard will follow up with the Content Creator via comment or direct message. In case a Content Creator becomes unresponsive or cannot complete the task, Wizards have to make a call: either extend the deadline, find another creator to take over (reassign the card), or in rare cases, move the card back to Approved (open for others) or Closed if it\u2019s not going to be done. Their role is to keep things moving toward completion.<\/li>\n<li><strong>Reviewing and Quality Control:<\/strong>\u00a0When a card is in\u00a0<strong>Ready for Review<\/strong>, Wizards (often the one who approved\/assigned it, or another with relevant knowledge) meticulously review the submitted content. They verify that it fulfills the request, is factually correct, and meets quality standards. If the content is good, they approve it. If it needs work, they compile clear, actionable feedback in the comments. Wizards might also loop in the original requester for their input if needed (&#8220;@RequesterName, does this meet what you were looking for?&#8221;). They ensure that any feedback is constructive and that the Content Creator knows exactly what to address in a revision. This may involve multiple review iterations, and Wizards coordinate this efficiently.<\/li>\n<li><strong>Approving Completion:<\/strong>\u00a0Once satisfied with the content, a Wizard will mark the task as completed. They move the card to\u00a0<strong>Completed<\/strong>\u00a0and update the status in the description (as per the template) to indicate approval. They also make sure the content is delivered to wherever it needs to go. For example, if the asset is a video that should be published on an official channel, a Wizard might handle that upload or coordinate with the team responsible. If it\u2019s an infographic, they might add it to the community wiki or resources page. While this step might be outside the board\u2019s direct scope, noting the outcome (where the content ended up) on the card is good practice.<\/li>\n<li><strong>Reward Distribution:<\/strong>\u00a0Wizards are responsible for distributing the promised\u00a0<strong>GNC rewards<\/strong>\u00a0to Content Creators once a task is completed. This involves initiating the token transfer from the community treasury or a rewards wallet. Wizards should follow whatever internal procedure exists for payments (which might require a second sign-off or a multi-sig transaction if it&#8217;s a DAO-like setup). Once done, they update the card (in the Completed template) with confirmation of payment (and possibly transaction details for transparency). This closes the loop, showing that the creator was compensated as agreed.<\/li>\n<li><strong>Board Maintenance and Oversight:<\/strong>\u00a0Beyond individual tasks, Wizards maintain the board\u2019s overall health. They ensure tags are used consistently and might refine tag categories over time. They archive or clean up old cards if the Completed column becomes too large (maybe moving very old completed cards to an archive board or changing their visibility). They also update any instructions on the board if processes change. For example, if a new type of asset becomes common (say, interactive demos), they might add a tag for it and mention it in the guidelines. Wizards could also periodically summarize board activity to the wider community (e.g., &#8220;Monthly update: 5 assets created and delivered this month!&#8221;), showcasing the productive output of the system.<\/li>\n<li><strong>Handling Conflicts or Issues:<\/strong>\u00a0If any conflicts arise (e.g., a requester is unhappy with the final content, or a creator disputes the amount of reward given), Wizards mediate and resolve the issue. They will refer to these guidelines and community rules. For instance, if a requester feels their request wasn\u2019t fully met even after revisions, a Wizard could discuss possible remedies (perhaps scheduling a follow-up asset or adjusting the content). If a Content Creator feels under-rewarded due to extra work, Wizards can consider a bonus or at least note the feedback for future reward calculations. The goal is to keep all parties satisfied and maintain a spirit of fairness.<\/li>\n<\/ul>\n<p>In summary, Wizards act as project managers and quality control for the Assets Request Board. Their active involvement at each stage (from vetting requests to final payout) is key to making the pipeline work. They ensure that the board remains a trusted system where good content is created efficiently and everyone\u2019s contributions are respected and rewarded.<\/p>\n<h2>Tags and Filters for Asset Categorization<\/h2>\n<p>To keep the Assets Request Board organized and easily navigable, we use <strong>tags (labels)<\/strong> on cards to categorize each request. Tags help filter and search for specific types of tasks or content. Here are the recommended tag categories and examples of each:<\/p>\n<p><code>Asset Type:<\/code> Tag the format of the content. Examples: <code>Graphic<\/code>, <code>Video<\/code>, <code>Article<\/code>, <code>Tutorial<\/code>, <code>Infographic<\/code>, <code>Animation<\/code>, etc. This allows anyone to quickly see what form the requested asset will take. <em>(For instance, a card tagged <\/em> <code>Video<\/code> vs. one tagged <code>Infographic<\/code> might be picked up by different creators specialized in those areas.)<\/p>\n<p><code>Difficulty\/Level:<\/code> Tag the intended audience skill level or complexity. Common tags: <code>Beginner<\/code>, <code>Intermediate<\/code>, <code>Advanced<\/code>. Use <code>Beginner<\/code> for content that explains basic concepts or is for newcomers; use <code>Advanced<\/code> for in-depth or technical content targeting experienced users. These tags help content creators gauge if a task aligns with their ability to simplify or elaborate on topics appropriately.<\/p>\n<p><code>Language:<\/code> If the community is multi-lingual, tag the language of the content. Examples: <code>English<\/code>, <code>Spanish<\/code>, <code>Polish<\/code>, <code>Mandarin<\/code>, etc. A request might even have multiple language tags if versions in different languages are needed. Language tags help in assigning creators who are fluent in those languages, and they allow community members to filter requests or completed assets by language.<\/p>\n<p><code>Topic\/Category:<\/code> (Optional, but very useful) Tag the subject matter or domain of the content. Examples might include <code>GridScript<\/code> (if the content relates to GRIDNET&#8217;s scripting language), <code>Wallet<\/code>, <code>Governance<\/code>, <code>DeFi<\/code>, <code>Security<\/code>, <code>Tutorial-Series<\/code>, etc. These tags will depend on common themes in the GRIDNET ecosystem. Topic tags group related content together and help creators with domain expertise find tasks that suit them.<\/p>\n<p><code>Priority\/Urgency:<\/code> If needed, use tags like <code>Urgent<\/code> or <code>High Priority<\/code> for tasks that have a time constraint or are particularly important. For example, a tutorial needed before an upcoming event or a graphic for an imminent announcement might be tagged urgent. This signals to creators that a task should be handled ASAP. (Wizards will assign these sparingly to keep everything from seeming high priority.)<\/p>\n<p><strong>Using tags:<\/strong> Requesters are encouraged to add relevant tags when creating the card (Deck app allows adding labels to cards). Wizards will review tags upon approval and adjust for consistency (they might have a standard set of label colors\/names). Content Creators can also suggest adding a tag if they see something missing or if the scope changes. On the Deck board, tags will appear as colored labels on each card, and users can filter the view by tag (for example, view only <code>Graphic<\/code> tasks or only <code>Completed<\/code> tasks tagged <code>Beginner<\/code> to find intro-level materials).<\/p>\n<p>Having a robust tagging system makes it much easier to navigate the board. For instance:<\/p>\n<ul>\n<li>A new Content Creator who specializes in video might filter by the <code>Video<\/code> tag to see all video requests.<\/li>\n<li>A community member looking for resources might filter the Completed column by <code>Tutorial<\/code> and <code>Beginner<\/code> tags to find all beginner tutorials that have been made.<\/li>\n<li>Wizards could use tags to generate reports (e.g., how many <code>Spanish<\/code> content pieces have been requested\/completed).<\/li>\n<\/ul>\n<p>Tags are an optional organizational tool, but when used consistently they greatly enhance the usability of the board.<\/p>\n<h2>Communication and Collaboration Expectations<\/h2>\n<p>Effective communication is crucial for a collaborative board like this. We emphasize transparency and openness so that everyone (requesters, creators, Wizards, and the wider community) can follow along. Here&#8217;s what is expected:<\/p>\n<ul>\n<li><strong>Use Deck Comments as the Primary Channel:<\/strong> Each card&#8217;s comment thread is the main channel for discussing that specific task. All significant interactions \u2013 clarifying questions, status updates, feedback, decisions \u2013 should happen in the <strong>comments<\/strong>. This keeps a written record tied to the task, which is helpful for accountability and for anyone later reviewing what was done. It also means information isn&#8217;t lost in private chats and everyone involved with the task stays informed.<\/li>\n<li><strong>Default to Public Communication:<\/strong> Since the board is publicly viewable, assume that anything you write on a card can be seen by the entire community. This is good for transparency: everyone sees what was requested, how it&#8217;s being addressed, and the outcome. It also encourages a respectful tone. Keep discussions constructive and professional. If you need to communicate sensitive information (e.g., sharing a private link or personal data), consider whether the card comment is appropriate or if a private message is better \u2013 but in general, keep things open.<\/li>\n<li><strong>Mention People for Clarity:<\/strong> The Deck app supports @mentions (or at least tagging users by name). Use these to direct comments to specific individuals when needed. For example, a Content Creator might write, &#8220;@WizardAlice I have a question about this requirement&#8230;&#8221; or a Wizard might write, &#8220;@CreatorBob please provide an update on your progress.&#8221; Mentions trigger notifications and ensure the comment isn&#8217;t missed by the intended party. Be mindful not to overuse mentions; use them when a response or action is needed from that person.<\/li>\n<li><strong>Use Talk (Chat) for Real-Time if Needed:<\/strong> Basecamp likely has an integrated chat (Talk). While the persistent record should live in Deck comments, sometimes a quick real-time chat can resolve issues faster (for brainstorming, troubleshooting technical issues, etc.). It&#8217;s fine to use Talk or direct messages for these quick sync-ups, especially among Wizards and creators. <strong>However, if any decision or important info comes out of a chat, summarize it back in the card comments.<\/strong> For example: &#8220;<em>(From our Talk discussion: We&#8217;ll proceed by splitting the video into two parts to make it easier to follow.)<\/em>&#8220;. This ensures the knowledge is captured on the board.<\/li>\n<li><strong>Regular Updates:<\/strong> Content Creators should provide updates at key milestones, as noted earlier. Wizards should also communicate any changes (like if a deadline is extended or a requirement changes). Regular small updates prevent people from wondering about the status. Even a quick &#8220;Progress is on track, just editing now&#8221; comment is helpful. Requesters typically won&#8217;t need to update much, but if their needs change or if they have additional input, they should voice it as soon as possible in the comments.<\/li>\n<li><strong>Respectful Feedback Loops:<\/strong> When giving feedback (Wizards\/requesters to creators), be specific and respectful. Comment on the work, not the person. For example, &#8220;The intro section is a bit too technical for beginners; could we simplify the language?&#8221; is constructive, whereas &#8220;This write-up is bad&#8221; is not helpful. Content Creators should also feel free to ask for clarification on feedback if something is unclear (&#8220;@WizardBob when you say more explanation in step 3, do you mean adding an example?&#8221;). Keeping this dialog respectful and clear ensures revisions go smoothly and learning happens on all sides.<\/li>\n<li><strong>Stay On-Topic:<\/strong> Keep the conversation in each card focused on that asset request. Tangential discussions should be moved elsewhere (general chat or a different card if it spawns a new idea). This helps maintain clarity. For instance, if a new idea comes up during discussion, a Wizard might say &#8220;That&#8217;s a great idea, let&#8217;s make a separate request for it so we don&#8217;t derail this task.&#8221;<\/li>\n<li><strong>Conflict Resolution:<\/strong> In the rare case of conflict (e.g., differing opinions on how to approach content or dissatisfaction with results), try to resolve it in comments with an open mind. Wizards will moderate if needed to reach a resolution. The public nature of the board means everyone should strive to be reasonable. Often, referring back to the original request or the guidelines can ground the discussion (&#8220;Our goal is to make this beginner-friendly, so let&#8217;s prioritize simplicity over depth in this tutorial.&#8221;).<\/li>\n<\/ul>\n<p>In summary, <strong>communicate openly, clearly, and respectfully.<\/strong> The Deck comments are the heartbeat of the board&#8217;s collaboration. By keeping most communication in one visible place, we ensure transparency and collective understanding. Optional side chats are fine for convenience, but the outcome of those should always loop back to the card. This way, anyone can read a card from top to bottom and understand the full story of that asset&#8217;s creation.<\/p>\n<h2>Example Workflow: From Request to Reward<\/h2>\n<p>To illustrate how the board functions, here&#8217;s an example scenario showing a request moving through the pipeline with all roles involved:<\/p>\n<ol>\n<li><strong>Request Submission:<\/strong> Alice, a community member, wants a tutorial infographic about setting up a GRIDNET node. She goes to the Assets Request Board and creates a card in <strong>New Request<\/strong> with the title &#8220;Infographic: How to Set Up a GRIDNET Node&#8221;. She fills in the template: describes that she wants a step-by-step graphic, tags it as <code>Graphic<\/code> + <code>Beginner<\/code> + <code>English<\/code>, and explains it&#8217;s for new users who prefer visual guides.<\/li>\n<li><strong>Wizards&#8217; Review and Approval:<\/strong> Bob, one of the Wizards, reviews Alice&#8217;s request. He sees it&#8217;s not a duplicate and would be useful for onboarding. He moves the card to <strong>Approved<\/strong>, and updates the description to add <strong>Reward: 50 GNC<\/strong>. He also notes in <strong>Status<\/strong> that it&#8217;s approved on today&#8217;s date, and sets <strong>Priority: High<\/strong> (because an upcoming workshop could use this). In a comment, Bob writes, &#8220;Approved \u2013 this will be great for newcomers. Looking for a Content Creator to take it on! (Need it in 2 weeks for the workshop.)&#8221;<\/li>\n<li><strong>Content Creator Volunteers:<\/strong> Carol, an approved Content Creator with graphic design skills, checks the board and sees the new approved request. In the comments, she writes: &#8220;@Bob I&#8217;d like to work on this infographic. I have experience making node setup guides. I can start right away and have a draft in a week.&#8221; This signals her interest publicly.<\/li>\n<li><strong>Assignment by Wizard:<\/strong> Bob confirms Carol as the assignee. He replies in a comment, &#8220;Great, @Carol, it&#8217;s yours! Thanks for taking this on.&#8221; He then moves the card to <strong>Assigned &amp; In Progress<\/strong>. In the card description, Bob adds &#8220;Assigned to Carol on [date], deadline Sept 30 (one week for draft, another for revisions before workshop)&#8221; in the <strong>Deadline\/Progress<\/strong> field. Now everyone knows Carol is working on it and by when.<\/li>\n<li><strong>Work in Progress Updates:<\/strong> Carol begins working on the infographic. She creates a checklist on the card (e.g., &#8220;1. Outline content, 2. Design draft, 3. Review with team, 4. Finalize graphic&#8221;). A couple of days in, Carol checks off &#8220;Outline content&#8221; and comments, &#8220;Outline done, starting on design layout now.&#8221; The next day, she comments again, &#8220;Halfway through the design, here&#8217;s a quick question: @Alice Should I include a section on system requirements, or keep it simple?&#8221; Alice (the requester) responds in a comment, &#8220;Include basic requirements, yes, that would help newbies.&#8221; This collaboration ensures the work meets the requester&#8217;s expectations.<\/li>\n<li><strong>Content Submission for Review:<\/strong> By the end of the week, Carol finishes the draft infographic. She uploads the image file to the card (or a share link if it&#8217;s large) and updates the description&#8217;s <strong>Deliverables<\/strong> with &#8220;Draft infographic image uploaded above.&#8221; She then moves the checklist item &#8220;Design draft&#8221; to done and comments, &#8220;@Bob @Alice The draft is ready for review. Please take a look and let me know your thoughts.&#8221; The card is now effectively in <strong>Ready for Review<\/strong> (Bob or another Wizard moves it officially, or Bob just knows to review it now).<\/li>\n<li><strong>Review and Feedback:<\/strong> Dan, another Wizard with an eye for content, joins Bob in reviewing the infographic. Bob notices the port number for connecting the node is missing, and Dan thinks the layout might benefit from a simpler step-by-step numbering. Bob comments, &#8220;Looks awesome overall! Two things: (1) Could you add the default port number in the network section? (2) Maybe number the steps 1-5 to make it even clearer.&#8221; Alice, the requester, also gives feedback: &#8220;This is great, just a minor spelling correction: &#8216;Initialize&#8217; is misspelled in step 3.&#8221; Carol responds, &#8220;Thanks for the feedback, on it! \ud83d\ude03&#8221;. She then makes the requested changes on her computer.<\/li>\n<li><strong>Re-submission and Approval:<\/strong> Carol uploads the revised infographic, replacing the old image (and notes &#8220;Updated image uploaded&#8221; in the Deliverables). She comments, &#8220;I&#8217;ve added the port number, numbered the steps, and fixed the spelling. @Bob @Dan please review the updated version.&#8221; Bob checks the new image and everything looks perfect now. He comments, &#8220;All set now, looks perfect. Thank you Carol!&#8221; A Wizard (Bob or Dan) moves the card to <strong>Completed<\/strong>, and updates the status: &#8220;Completed \u2013 approved on [date].&#8221;<\/li>\n<li><strong>Payment and Acknowledgment:<\/strong> After marking it Completed, Bob initiates the reward payment of 50 GNC to Carol&#8217;s wallet. He then edits the <strong>Reward Payment<\/strong> field on the card: &#8220;50 GNC transferred to Carol on [date] (Tx ID: &#8230;)&#8221; and comments &#8220;Reward sent. \ud83c\udf89 Great work @Carol, and thanks @Alice for the request!&#8221; Carol replies with a thank you, and Alice expresses her excitement to share the infographic at the workshop. The task is now fully closed out.<\/li>\n<\/ol>\n<p>This example shows the full lifecycle of a request through the board: a clear request, active Wizard facilitation, a Content Creator&#8217;s work and communication, collaborative review with the requester and Wizards, and final delivery with reward. All of it happened transparently on the board, with each stage clearly indicated by the card&#8217;s column and updates.<\/p>\n<h2 class=\"p2\"><span class=\"s1\"><b>Public-Facing Project Incubation Board<\/b><\/span><\/h2>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"size-full wp-image-676660 aligncenter\" src=\"https:\/\/gridnet.org\/wpp\/wp-content\/uploads\/2025\/04\/Screenshot-2025-04-25-at-23.24.20.png\" alt=\"\" width=\"1075\" height=\"1090\" srcset=\"https:\/\/gridnet.org\/wpp\/wp-content\/uploads\/2025\/04\/Screenshot-2025-04-25-at-23.24.20.png 1075w, https:\/\/gridnet.org\/wpp\/wp-content\/uploads\/2025\/04\/Screenshot-2025-04-25-at-23.24.20-75x75.png 75w\" sizes=\"auto, (max-width: 1075px) 100vw, 1075px\" \/><\/p>\n<p class=\"p1\"><span class=\"s1\"><b>Board Name:<\/b> <i>Project Incubation<\/i> (Public)<br \/>\n<b>Purpose:<\/b> This board serves as an open incubator for community-submitted development ideas and <b>GNC<\/b> funding proposals. It supports all project types \u2013 from UI dApps and integrations to developer tools \u2013 and guides them through an 8-stage workflow from initial proposal to funded project. The board is visible to everyone (readable by the public), and community members can create and edit their own cards, comment on others, and participate in proposal evaluation (including voting via polls when deployed). Internal Wizards oversee the process, helping to move proposals through stages and ensure integrity. This openness lets the community directly influence project direction, embodying decentralized governance by allowing bottom-up contributions and feedback.<\/span><\/p>\n<p class=\"p3\"><span class=\"s1\"><b>Board Structure: 8-Stage Workflow<\/b><\/span><\/p>\n<p class=\"p3\"><img loading=\"lazy\" decoding=\"async\" class=\"alignnone size-full wp-image-676671\" src=\"https:\/\/gridnet.org\/wpp\/wp-content\/uploads\/2025\/04\/Screenshot-2025-04-25-at-23.39.19.png\" alt=\"\" width=\"1702\" height=\"1141\" \/><\/p>\n<p class=\"p1\"><span class=\"s1\">The Project Incubation board is organized into eight sequential lists (columns), each representing a key stage in the project development and funding lifecycle. A card (proposal) will move through these lists as it matures. Below are the lists and their purposes, along with a template of what information each card should contain at that stage:<\/span><\/p>\n<h3 class=\"p4\"><span class=\"s1\"><b>1. Proposal (Ideation Stage)<\/b><\/span><\/h3>\n<p class=\"p1\"><span class=\"s1\"><b>Purpose:<\/b> The Proposal list is the entry point for all new ideas. Community members submit their project proposals here to kick off the incubation process. This stage is all about capturing the <b>what<\/b> and <b>why<\/b> of the idea.<\/span><\/p>\n<p class=\"p1\"><span class=\"s1\"><b>Card Template (Proposal):<\/b> When creating a card in the Proposal column, the proposer should include:<\/span><\/p>\n<ul class=\"ul1\">\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Title:<\/b> A concise project name or title.<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Proposer(s):<\/b> Name or username of the proposer (and team, if any).<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Summary:<\/b> A brief overview of the idea, its goals, and expected impact.<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Problem Statement:<\/b> The problem or need the project addresses.<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Proposed Solution:<\/b> Description of the solution or approach being suggested.<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Project Type\/Category:<\/b> What type of project it is (e.g. <i>UI dApp<\/i>, <i>Integration<\/i>, <i>Tool<\/i> \u2013 can also be indicated with a tag).<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Resources Required (Optional):<\/b> Any specific resources or support needed (funding, expertise, etc.).<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>References\/Links (Optional):<\/b> Links to related discussions, documents, or prior work (if any).<\/span><\/li>\n<\/ul>\n<p class=\"p1\"><span class=\"s1\"><b>How it works:<\/b> A community member creates a card with the above details, giving enough information for others to understand the idea. The card represents a live proposal that others can now see and comment on. This stage encourages <b>open innovation<\/b> \u2013 anyone in the community can put forward a creative idea. At this point, the idea is informal; the emphasis is on clarity of the concept and its value to the ecosystem. If the proposal is unclear or incomplete, Wizards may assist the proposer to refine the card so that it\u2019s ready for the next stage.<\/span><\/p>\n<h3 class=\"p4\"><span class=\"s1\"><b>2. Community Validation (Feedback &amp; Discussion)<\/b><\/span><\/h3>\n<p class=\"p1\"><span class=\"s1\"><b>Purpose:<\/b> Once a proposal has been put forward, it moves into <b>Community Validation<\/b>. This stage opens the floor for community feedback, discussion, and initial validation of the idea\u2019s merit. Decentralized governance comes to life here as community members collectively evaluate proposals.<\/span><\/p>\n<p class=\"p1\"><span class=\"s1\"><b>What happens here:<\/b> In this list, community members review the proposal. They use Deck\u2019s commenting feature to discuss the idea, ask questions, and offer suggestions. The goal is to gauge public interest and improve the proposal through crowd input. In some cases, a <b>poll<\/b> may be attached to the card (for example, a link to a Bootcamp Poll or an on-chain voting mechanism) to formally measure community support or rank priorities. For instance, a simple poll might ask \u201cShould this project move forward to technical assessment?\u201d with yes\/no options.<\/span><\/p>\n<p class=\"p1\"><span class=\"s1\"><b>Card Template (Community Validation):<\/b> As the card evolves in this stage, it should be updated with:<\/span><\/p>\n<ul class=\"ul1\">\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Community Feedback Summary:<\/b> A running summary or list of key points from the discussion (maintained by the proposer or a moderator). For example, note common questions, any proposed changes, or general sentiment (e.g. \u201c5 comments in support, 1 concern about feasibility\u201d).<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Poll Results (if applicable):<\/b> If a vote was conducted, record the outcome (e.g. 85% of community voters support moving forward).<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Proposer\u2019s Response:<\/b> The proposer can update the card description to address major feedback, clarifying how they will adjust the idea or providing answers to questions.<\/span><\/li>\n<\/ul>\n<p class=\"p1\"><span class=\"s1\"><b>How it contributes:<\/b> This stage ensures the proposal has community buy-in before resources are spent on it. It leverages the wisdom of the crowd for <b>validation<\/b>. A strong positive response (lots of upvotes or supportive comments) signals the project is worth pursuing, whereas lukewarm interest or unresolved criticisms might signal caution. By the end of Community Validation, the proposal should be more refined and have a clear indication of community sentiment. Wizards or moderators will look for a consensus or at least a constructive discussion before advancing the card. If the idea passes this community review, it proceeds to the next stage. (If it fails to gain support or the proposer withdraws it, the card may be moved to an archive or \u201cClosed\u201d list for record-keeping.)<\/span><\/p>\n<h3 class=\"p4\"><span class=\"s1\"><b>3. Technical Assessment (Feasibility Review)<\/b><\/span><\/h3>\n<p class=\"p1\"><span class=\"s1\"><b>Purpose:<\/b> In the Technical Assessment stage, the proposal is examined for feasibility and technical soundness. While the community can provide input, this phase is primarily handled by experienced developers or domain experts (the internal Wizards team or appointed reviewers). This adds a layer of expert governance to ensure the project is viable and aligns with GRIDNET\u2019s technology stack and standards.<\/span><\/p>\n<p class=\"p1\"><span class=\"s1\"><b>What happens here:<\/b> A designated technical reviewer is assigned to the card (using Deck\u2019s card assignment feature, the reviewer\u2019s name\/avatar will be attached to the card). The reviewer conducts due diligence on the proposal\u2019s technical aspects. This may involve checking the proposed solution\u2019s architecture, identifying potential challenges, security concerns, or resource requirements, and evaluating whether the idea is realistically achievable with the available technology. The outcome can be suggestions to modify the approach, an endorsement of technical viability, or in some cases, a recommendation not to proceed if there are insurmountable issues.<\/span><\/p>\n<p class=\"p1\"><span class=\"s1\"><b>Card Template (Technical Assessment):<\/b> The card\u2019s description or comments should be updated by the reviewer with a <b>Technical Evaluation<\/b> section, including:<\/span><\/p>\n<ul class=\"ul1\">\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Feasibility Analysis:<\/b> Notes on how the project can be implemented. E.g., which platform or language it would use, any required integration with existing systems, etc.<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Challenges &amp; Risks:<\/b> Identification of technical risks or uncertainties (for example, \u201crequires significant computational resources\u201d or \u201cdependency on unreleased API\u201d).<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Recommendations:<\/b> Suggestions for improvements or adjustments (like using a different approach to solve the problem, or phasing the project).<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Technical Green Light:<\/b> A clear statement of whether the project is technically <b>Approved<\/b> to move forward, <b>Needs Revisions<\/b>, or <b>Not Feasible<\/b>. This can be a brief conclusion in the card (e.g., \u201cApproved to proceed \u2013 no major blockers identified\u201d or \u201cNot recommended: relies on unsupported tech\u201d).<\/span><\/li>\n<\/ul>\n<p class=\"p1\"><span class=\"s1\"><b>Result:<\/b> This stage injects expert oversight, ensuring that enthusiasm is tempered with practicality. If the technical assessment is positive, the card moves on. If issues are found, the proposer might be asked to revise the proposal or it could be put on hold. By performing this in the open (the card is still on a public board), the community gains insight into the reasoning, which builds trust. It also invites technically skilled community members to weigh in if they have knowledge, further decentralizing the expertise involved.<\/span><\/p>\n<h3 class=\"p4\"><span class=\"s1\"><b>4. Project Specification (Detailed Planning)<\/b><\/span><\/h3>\n<p class=\"p1\"><span class=\"s1\"><b>Purpose:<\/b> After passing technical vetting, the idea enters Project Specification. The aim here is to develop a full project plan and specification before any funding is requested. This stage turns a validated idea into a concrete blueprint, ensuring all details are fleshed out. It\u2019s a collaborative effort \u2013 the proposer, Wizards, and other contributors might work together on the specifics.<\/span><\/p>\n<p class=\"p1\"><span class=\"s1\"><b>What happens here:<\/b> The card in the Project Specification list represents a draft of the full project plan. The proposer (or project team) will expand the proposal into a detailed specification document. This may be done in a shared document (like a Bootcamp document or markdown file) linked or attached to the card. The specification should cover exactly what will be built, how, and by whom, serving as a single source of truth for the project\u2019s scope.<\/span><\/p>\n<p class=\"p1\"><span class=\"s1\"><b>Card Template (Project Specification):<\/b> At this stage, the card should include or link to:<\/span><\/p>\n<ul class=\"ul1\">\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Specification Document:<\/b> A link or attachment to a detailed spec (could be a Bootcamp\u00a0 doc). This document typically includes sections such as <i>Objective<\/i>, <i>Functional Requirements<\/i>, <i>Technical Architecture<\/i>, and <i>User Experience<\/i> details if applicable.<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Scope &amp; Deliverables:<\/b> A clear list of what the project will deliver (features, components, outputs). For example, \u201cDeliverable 1: Web UI for X, Deliverable 2: Smart contract Y\u2026\u201d<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Timeline\/Milestones:<\/b> An estimated timeline divided into milestones. E.g., \u201cMonth 1: Prototype, Month 2: MVP release, Month 3: Testing&#8230;\u201d Each milestone might later tie to funding tranches.<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Team &amp; Roles:<\/b> Identify who will work on the project. List confirmed team members or note if contributors are needed for certain roles (developer, designer, etc.). Community members might volunteer here if the project needs help.<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Initial Budget Estimation:<\/b> A rough estimate of resources needed (not the formal request yet, but an outline: e.g., \u201cApproximately 1000 GNC for development over 3 months\u201d).<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Risks &amp; Dependencies:<\/b> Any outstanding risks or dependencies (e.g., \u201cWaiting on API release in next SDK\u201d or \u201cNeed partnership with X for data\u201d).<\/span><\/li>\n<\/ul>\n<p class=\"p1\"><span class=\"s1\"><b>How it contributes:<\/b> The Project Specification stage is crucial for <b>project integrity and success<\/b>. By planning thoroughly, it increases the project\u2019s chance of delivering value and using funds effectively. This stage also demonstrates transparency \u2013 the entire community can see the detailed plan and provide final input or spot issues (via comments on the card or the spec document). It encourages would-be collaborators from the community to join the effort if they see a well-defined plan. Once the specification is solid and agreed upon by the proposer and relevant experts, the project is ready to seek funding.<\/span><\/p>\n<h3 class=\"p4\"><span class=\"s1\"><b>5. Grant Application Preparation (Funding Proposal)<\/b><\/span><\/h3>\n<p class=\"p1\"><span class=\"s1\"><b>Purpose:<\/b> In this stage, the team prepares a formal <b>Grant Application<\/b> for the project, based on the specification. This is a packaging of the project plan into a format required by the funding body (e.g., GRIDNET\u2019s grant committee or a DAO funding process). It translates the plan into a request for resources (GNC tokens) and commitments to deliverables.<\/span><\/p>\n<p class=\"p1\"><span class=\"s1\"><b>What happens here:<\/b> The card moves to Grant Application Preparation once the project spec is ready. The proposer (with possible help from Wizards or a grants support team) compiles all required information into the standard grant proposal format. This might involve filling out a grant template form, writing a cover letter, or creating slides \u2013 whatever the process requires. It\u2019s an internal preparation phase, but on this public board the community can still follow along and offer last-minute suggestions if needed.<\/span><\/p>\n<p class=\"p1\"><span class=\"s1\"><b>Card Template (Grant Application):<\/b> The card at this stage should track the tasks and content of the application, such as:<\/span><\/p>\n<ul class=\"ul1\">\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Grant Proposal Document:<\/b> A link to the completed grant application (for example, a PDF or form output). This document typically includes an executive summary of the project, background of the team, the detailed plan (from stage 4) condensed, and the funding request.<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Budget Breakdown:<\/b> Clear itemization of the funding needs in GNC. E.g., personnel costs, equipment, audits, etc., totaling the requested amount. Each item should tie to parts of the project or milestones.<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Milestones &amp; Deliverables:<\/b> A reiteration of the project milestones, now framed as conditions for grant disbursement. For instance, \u201cMilestone 1 (20% of funds): Completion of feature X by Date Y, deliverable: code on GitHub\u201d and so on.<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Supporting Materials:<\/b> Any extra materials required, such as team CVs, references to prior work, mockups or prototypes (if they have been developed early). These can be attached or linked in the card.<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Checklist of Application Steps:<\/b> (Optional) A checklist in the card\u2019s comment or description to ensure all application steps are done \u2013 e.g., \u201c\u2705 Filled online application form,\u201d \u201c\u2705 Obtained 3 community endorsements,\u201d \u201c\u2705 Prepared demo video.\u201d<\/span><\/li>\n<\/ul>\n<p class=\"p1\"><span class=\"s1\"><b>How it contributes:<\/b> This stage formalizes the project for funding, ensuring nothing is missing when the application goes to review. It demonstrates to the community that funding is requested based on a well-documented plan and fair budget, reinforcing trust. Even though this is a formal paperwork stage, doing it via the board keeps the process transparent \u2013 the community can see that the team is asking for X amount of GNC and what they promise in return. It also invites any community oversight (for example, if someone notices the budget is too high for a certain item, they could comment). By the end of this stage, the project is ready to be evaluated for approval.<\/span><\/p>\n<h3 class=\"p4\"><span class=\"s1\"><b>6. Grant Review (Committee Evaluation)<\/b><\/span><\/h3>\n<p class=\"p1\"><span class=\"s1\"><b>Purpose:<\/b> In the Grant Review stage, the submitted application is evaluated by the authorized decision-makers \u2013 for instance, GRIDNET\u2019s grant committee, core team, or a governance council. This stage focuses on due diligence and deliberation on whether the project should receive funding. It\u2019s a critical checkpoint to uphold accountability in fund allocation.<\/span><\/p>\n<p class=\"p1\"><span class=\"s1\"><b>What happens here:<\/b> The card is now in the hands of the reviewing body. Reviewers will read the grant proposal and possibly meet (offline or online) to discuss it. They will use the card to document their evaluation and any requests for clarification. Since this board is public, the review stage can also be partially transparent: while internal deliberations might happen privately, the outcomes and major feedback are recorded on the card for the community to see. This way, the community understands why a project was or wasn\u2019t approved, which is vital for fair decentralized governance.<\/span><\/p>\n<p class=\"p1\"><span class=\"s1\"><b>Card Template (Grant Review):<\/b> As the review progresses, the card should be updated to reflect the review status:<\/span><\/p>\n<ul class=\"ul1\">\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Reviewer Comments:<\/b> A section where each reviewer (or the committee collectively) notes their comments or concerns. For example: \u201cReviewer A: Project aligns with our roadmap, good team. Reviewer B: Concerned about security aspects \u2013 require audit in plan. Reviewer C: Supports funding half now, half upon milestone 2.\u201d<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Questions for Proposer:<\/b> If the committee has questions, they can be listed here (and the proposer can answer in the card comments or by updating the application document). For example: \u201cPlease clarify how the maintenance of the dApp will be funded after grant.\u201d<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Conditional Requirements:<\/b> Any conditions the committee would require for approval. E.g., \u201cMust add a detailed testing plan\u201d or \u201cFind an additional senior developer to co-lead the project.\u201d These should be documented on the card so the proposer can respond.<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Status Indicator:<\/b> An explicit note of the status, such as <i>Under Review<\/i>, <i>Needs Revision<\/i>, or <i>Pending Decision<\/i>. This can be simply written in the description or as a tag on the card like \u201cReview In Progress\u201d.<\/span><\/li>\n<\/ul>\n<p class=\"p1\"><span class=\"s1\"><b>Transparency and outcome:<\/b> Throughout Grant Review, the card acts as a transparent log of the evaluation. The community can observe that the proposal is being carefully vetted, which adds credibility to the process (no \u201cblack box\u201d decisions). If the reviewers find significant issues, they may ask the proposer to move the card back to \u201cGrant Application Preparation\u201d to adjust the proposal (for example, revise the budget or scope) before resubmitting. Otherwise, once all concerns are resolved and if the consensus is positive, the committee will proceed to approval. (If ultimately rejected, the card would be moved to a \u201cRejected\u201d or archive list with an explanation note, to close the loop publicly.)<\/span><\/p>\n<h3 class=\"p4\"><span class=\"s1\"><b>7. Grant Approval (Decision Stage)<\/b><\/span><\/h3>\n<p class=\"p1\"><span class=\"s1\"><b>Purpose:<\/b> This stage signifies that the project has been officially approved for a grant. It is the confirmation point where the governance process (community + committee) converges on a positive decision. Moving a card to <b>Grant Approval<\/b> list means the project will receive funding.<\/span><\/p>\n<p class=\"p1\"><span class=\"s1\"><b>What happens here:<\/b> The Grant Approval list holds cards that have passed review and are authorized to be funded. When a card reaches this list, it\u2019s effectively a green light. Typically, a formal notification is given to the proposer (outside of Deck, perhaps via email or an announcement), but the Deck card is updated to mark the approval and outline the final terms. This stage is mostly a celebratory and record-keeping one on the public board, as the heavy lifting was done in review.<\/span><\/p>\n<p class=\"p1\"><span class=\"s1\"><b>Card Template (Grant Approval):<\/b> The card should be updated to record the approval details:<\/span><\/p>\n<ul class=\"ul1\">\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Approval Date:<\/b> The date when the grant was approved (and by whom, e.g., committee vote or executive sign-off).<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Approved Funding Amount:<\/b> Confirm the amount of GNC to be awarded (this might match the request or be adjusted during review).<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Disbursement Plan:<\/b> Note how the funds will be disbursed. E.g., \u201c50% upfront, 50% after milestone 2 as per the grant agreement.\u201d This ensures everyone knows the terms.<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Grant Agreement:<\/b> If there\u2019s a formal agreement or contract to sign, mention that it\u2019s completed. Possibly link to a public statement or a hashed reference of the agreement for transparency.<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Next Steps:<\/b> Outline immediate next steps for the team. For example, \u201cProposer to provide wallet address for GNC transfer\u201d or \u201cOnboarding to project management repository.\u201d Also, encourage the team to start execution and maybe note that progress updates will be expected.<\/span><\/li>\n<\/ul>\n<p class=\"p1\"><span class=\"s1\"><b>How it contributes:<\/b> This stage on the board serves as an <b>official public record<\/b> of the approval. It demonstrates decentralized decision-making coming to fruition \u2013 an idea from the community made it through all checks and is now supported with resources. It also signals to the community which projects will be worked on, fostering a sense of collective achievement. By seeing the card in \u201cGrant Approval,\u201d other community members know this project is definitely happening, which might inspire collaboration or similar proposals. After logging these details, the card is ready to move to the final stage, triggering the actual funding transfer.<\/span><\/p>\n<h3 class=\"p4\"><span class=\"s1\"><b>8. Financing in GNC (Funding &amp; Handover)<\/b><\/span><\/h3>\n<p class=\"p1\"><span class=\"s1\"><b>Purpose:<\/b> The final stage is <b>Financing in GNC<\/b>, where the approved grant is executed \u2013 i.e., funds are transferred in the GRIDNET Coin (GNC) cryptocurrency to the project team. This list holds projects that have been funded and are now in the implementation phase (often, work on them will continue outside this board or be tracked in a different project management space, but they remain here as a completed incubator item).<\/span><\/p>\n<p class=\"p1\"><span class=\"s1\"><b>What happens here:<\/b> Once the funding transaction is made, the card is moved to Financing in GNC to mark completion of the incubation pipeline. The emphasis is on documenting that the funds were delivered and the project is officially kicked off. This stage closes the loop of accountability: the community can verify that the promised funding was indeed given out, fulfilling the transparent governance cycle.<\/span><\/p>\n<p class=\"p1\"><span class=\"s1\"><b>Card Template (Financing):<\/b> Each card in this final column should include:<\/span><\/p>\n<ul class=\"ul1\">\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Payment Details:<\/b> Record of the funding transaction. For example, \u201cTransferred 1000 GNC on 2025-03-01 to wallet address XYZ.\u201d This could include a transaction ID or link to a block explorer for verification.<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Funding Schedule:<\/b> If the funds are split into multiple payments, list the schedule (e.g., \u201cInitial disbursement of 500 GNC done, remaining 500 GNC scheduled after milestone 2 in June 2025\u201d). Mark completed payments with a check or note.<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Point of Contact:<\/b> Identify who in the team or the foundation is responsible for financial coordination. E.g., \u201cTreasurer: @wizard-alice facilitated the transfer.\u201d<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Project Handover:<\/b> Note where the project will be tracked going forward. Possibly link to a new Deck board, a GitHub repository, or a project page where development updates will occur. For instance, \u201cProject development tracked on <a href=\"https:\/\/chatgpt.com\/c\/link\"><span class=\"s2\">Project X Repo<\/span><\/a> and monthly updates will be posted on forum.\u201d<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Status Note:<\/b> Confirm that the incubation process is complete. E.g., \u201cStatus: Funded and in progress (Incubation complete).\u201d<\/span><\/li>\n<\/ul>\n<p class=\"p1\"><span class=\"s1\"><b>Outcome:<\/b> The card (and the board) has now served its purpose for this project. The project team will carry on with development, and the community can follow progress through the provided links or updates. The presence of this final stage in a public board is a powerful indicator of accountability in a decentralized system \u2013 it shows that not only was a decision made, but the execution (payment of funds) actually happened as approved. This fosters trust in the governance process because every step from idea to funding is visible and documented.<\/span><\/p>\n<p class=\"p1\"><span class=\"s1\"><i>(Optional: It\u2019s good practice for historical record to keep these funded cards on the board for a while, or move them to an <\/i><b><i>\u201cCompleted Projects\u201d<\/i><\/b><i> archive column later, so anyone can review past funded proposals and their details.)<\/i><i><\/i><\/span><\/p>\n<p class=\"p1\"><img loading=\"lazy\" decoding=\"async\" class=\"size-full wp-image-676676 aligncenter\" src=\"https:\/\/gridnet.org\/wpp\/wp-content\/uploads\/2025\/04\/Screenshot-2025-04-26-at-00.05.50.png\" alt=\"\" width=\"1427\" height=\"913\" \/><\/p>\n<h3 class=\"p3\"><span class=\"s1\"><b>Useful Tags for Project Incubation Board<\/b><\/span><\/h3>\n<p class=\"p1\"><span class=\"s1\">Tags in Deck help categorize and filter cards. For the Project Incubation board, we will use a set of tags to label proposals by type and other attributes. Tags ensure that users can quickly find specific kinds of projects or see the distribution of proposals. Some useful tags include:<\/span><\/p>\n<ul class=\"ul1\">\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>UI dApp<\/b> \u2013 for user-facing decentralized applications (front-end projects, wallets, dApp UIs).<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Integration<\/b> \u2013 for projects that integrate GRIDNET with other platforms or services (APIs, bridges, plugins).<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Tool\/Utility<\/b> \u2013 for developer tools, libraries, testing frameworks, or any utility that aids the ecosystem.<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Core Protocol<\/b> \u2013 for proposals that involve changes or improvements to the core GRIDNET protocol or infrastructure.<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Documentation\/Education<\/b> \u2013 for projects focused on creating documentation, tutorials, or educational content.<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Research\/Experiment<\/b> \u2013 for exploratory projects or research initiatives that might not result in a product but add knowledge (e.g., a scalability study).<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Small Grant<\/b> \u2013 (if applicable) to mark proposals requesting a small amount of funding, as defined by the community\u2019s standards.<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Large Grant<\/b> \u2013 to mark higher-budget proposals. This helps reviewers give appropriate scrutiny to big projects.<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>High Priority<\/b> \u2013 a tag that moderators can use if a proposal aligns with urgent ecosystem needs or strategic goals (this can signal to the community which ideas are especially important).<\/span><\/li>\n<\/ul>\n<p class=\"p1\"><span class=\"s1\">Each card can have multiple tags. For example, a proposal for a \u201cMobile Wallet dApp integrating GRIDNET with Hardware Wallets\u201d might be tagged <b>UI dApp<\/b> and <b>Integration<\/b>. Tags are configured at the board level, and since Bootcamp Deck allows custom tags per board, we can maintain this list as the standard \u00a0Using tags consistently will make it easier to filter proposals (Deck\u2019s search can filter by tag), and color-coding tags can visually distinguish categories. This tagging system complements the stage columns by adding another dimension of information without cluttering the board.<\/span><\/p>\n<h3 class=\"p3\"><span class=\"s1\"><b>Community Instructions and Usage Guidelines (Public Board)<\/b><\/span><\/h3>\n<p class=\"p1\"><span class=\"s1\"><i>Overview:<\/i> The <b>Project Incubation Board<\/b> is open to all community members for proposing and developing project ideas. It operates under a set of guidelines to ensure a productive, respectful, and effective collaboration environment. Below is an overview of how to use this board, the rules of engagement, and tips for getting the most out of the incubation process.<\/span><\/p>\n<h3 class=\"p1\"><span class=\"s1\"><b>How to Propose a Project:<\/b><b><\/b><\/span><\/h3>\n<ol class=\"ol1\">\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Submit a New Proposal:<\/b> To propose a project, create a new card in the <b>Proposal<\/b> column. Only create one card per project. Give it a clear title and fill out the required details following the Proposal template (problem, solution, etc.). This information helps others understand and evaluate your idea.<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Use Tags Appropriately:<\/b> Before saving your card, assign relevant tags (from the list of tags above). For example, tag your project\u2019s category (dApp, integration, etc.). This is important for visibility \u2013 many people will browse by tags to find projects they are interested in.<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Do Not Edit Others\u2019 Proposals:<\/b> You are allowed to edit <i>your own<\/i> cards to refine your proposal, but please <b>do not edit someone else\u2019s proposal card<\/b> without permission. Everyone should feel ownership over their idea. If you have suggestions, use comments instead of editing the description. Moderators (Wizards) may edit cards to format or clarify details, but they will usually comment first.<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>One Proposal, One Card:<\/b> Avoid duplicate proposals. If your idea is similar to an existing one, consider commenting on the existing card and perhaps collaborating, instead of creating a new card.<\/span><\/li>\n<\/ol>\n<h3 class=\"p1\"><span class=\"s1\"><b>Engaging with Proposals (Community Feedback):<\/b><b><\/b><\/span><\/h3>\n<ul class=\"ul1\">\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Comment Constructively:<\/b> If you see a proposal you like or have concerns about, click on the card and add a comment. Feedback should be constructive and courteous. For example, ask questions (\u201cHave you considered using X approach?\u201d), offer help (\u201cI can assist with design if needed\u201d), or express support (\u201cThis is a great idea, it would really help users like me\u201d). Avoid vague criticisms \u2013 be specific and helpful.<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Voting:<\/b> When a proposal is in <b>Community Validation<\/b>, look for a poll link or vote indicator in the card. Participate in polls to signal your support or concerns. Each community member typically has one vote per poll; use it to help good ideas rise. If no formal poll is provided, you can still show support by commenting \u201c+1\u201d or reacting if the platform allows (some integrations might enable emoji reactions).<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Spread the Word:<\/b> It\u2019s okay to share the link to a card with others in the community to draw more attention to it (e.g., in the forum or chat), but please keep discussion on the card or official channels so everything is documented.<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Respect and Moderation:<\/b> Follow the community code of conduct. Harassment, spam, or off-topic comments will be removed. Wizards (moderators) will intervene if discussions become unproductive or disrespectful. Our goal is to maintain a welcoming environment for contributors of all experience levels.<\/span><\/li>\n<\/ul>\n<h3 class=\"p1\"><span class=\"s1\"><b>Progressing Through Stages:<\/b><b><\/b><\/span><\/h3>\n<ul class=\"ul1\">\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Stay Informed:<\/b> You can watch cards by subscribing or checking the board regularly. When a card moves to a new stage, it means it has passed certain checks (community validation, technical review, etc.). The card description will be updated at each stage with new information \u2013 make sure to read those updates if you\u2019re following that project.<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Collaboration Opportunities:<\/b> If a project reaches <b>Project Specification<\/b> and you have skills to contribute, comment to volunteer. Many proposals can become group efforts. This is encouraged \u2013 open-source development thrives on collaboration. The proposer can add collaborators by mentioning them or even by sharing access if needed (though by default any logged-in user can comment on the card).<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Role of Wizards:<\/b> The Wizards team (core maintainers) helps facilitate this board. They might move cards to the next stage after verifying criteria are met, or help organize information. For example, once your proposal has a lot of community support, a Wizard will move it to Technical Assessment and assign an expert. Wizards also ensure that grant applications are complete before going to review. They are here to help the process, not to dominate it \u2013 final decisions rest on the structured process (community input and committee approval).<\/span><\/li>\n<\/ul>\n<h3 class=\"p1\"><span class=\"s1\"><b>Board Rules &amp; Integrity:<\/b><b><\/b><\/span><\/h3>\n<ul class=\"ul1\">\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Transparency:<\/b> All major steps and decisions should be documented on the card. If you have an off-platform discussion (say a call to discuss the project), summarize the outcome in a comment so the community isn\u2019t left in the dark. Transparency builds trust in this decentralized process.<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>No Sensitive Personal Data:<\/b> Do not post private personal information (like personal phone numbers, etc.) on this public board. Communication can be done via usernames and official channels. Remember this board is world-visible; keep the content professional and project-related.<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Intellectual Property:<\/b> By submitting a proposal here, you agree that the idea (unless otherwise noted) is open for the community. Do not post proprietary ideas you aren\u2019t willing to develop openly. The spirit is open-source \u2013 if you need to keep something secret, this public board isn\u2019t the place.<\/span><\/li>\n<li class=\"li1\"><b><\/b><span class=\"s1\"><b>Conflict Resolution:<\/b> If you disagree with a decision (e.g., your proposal wasn\u2019t approved), you can ask for clarification on the card or in the community forum. There is a appeals or re-submission process: significantly revised proposals can be re-submitted or moved back to earlier stages, but coordinate with a Wizard to do so. We aim for fair consideration of all ideas.<\/span><\/li>\n<\/ul>\n<p class=\"p1\"><span class=\"s1\"><b>How this Board Fosters Decentralized Governance:<\/b> By following these guidelines, the Project Incubation board allows anyone in the community to have a voice in what gets built. Ideas are not top-down mandated; they emerge from the community and are evaluated in the open. Community members directly influence decisions through feedback and votes, aligning with decentralized governance principles. Meanwhile, the structured 8-stage pipeline ensures that each idea is responsibly vetted (for technical feasibility and impact) before community funds are spent, which protects the ecosystem from poorly planned projects. In summary, <b>this board is a public square for innovation<\/b>, where transparency and collaboration turn grassroots ideas into funded, actionable projects.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Prologue: From Tribal Circles to Digital Loops For almost the entirety of human existence, we have organized ourselves in circles. The earliest human tribes sat around fires in circular formations, sharing resources, stories, and tasks. Hunter-gatherers distributed duties based on skills and needs: some hunted, others gathered, some crafted tools, while others cared for children. [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":676671,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[110],"tags":[],"class_list":["post-676562","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-fundraising"],"_links":{"self":[{"href":"https:\/\/gridnet.org\/wpp\/index.php\/wp-json\/wp\/v2\/posts\/676562","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/gridnet.org\/wpp\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/gridnet.org\/wpp\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/gridnet.org\/wpp\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/gridnet.org\/wpp\/index.php\/wp-json\/wp\/v2\/comments?post=676562"}],"version-history":[{"count":47,"href":"https:\/\/gridnet.org\/wpp\/index.php\/wp-json\/wp\/v2\/posts\/676562\/revisions"}],"predecessor-version":[{"id":676926,"href":"https:\/\/gridnet.org\/wpp\/index.php\/wp-json\/wp\/v2\/posts\/676562\/revisions\/676926"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/gridnet.org\/wpp\/index.php\/wp-json\/wp\/v2\/media\/676671"}],"wp:attachment":[{"href":"https:\/\/gridnet.org\/wpp\/index.php\/wp-json\/wp\/v2\/media?parent=676562"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/gridnet.org\/wpp\/index.php\/wp-json\/wp\/v2\/categories?post=676562"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/gridnet.org\/wpp\/index.php\/wp-json\/wp\/v2\/tags?post=676562"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}