Overview
The GIP process includes both the stages and acceptance criteria that a proposal hits as it is fleshed out in this repo, as well as a meta-process that takes place before, during, and after a GIP is written in order to build credibility and community consensus behind an idea.
The high-level process is captured in the diagram below:
The author(s) should do the leg work to assess whether their idea is a good one that is likely to be supported by the community. This includes discussing the idea in public spaces such as Discord, Twitter, and The Graph forum.
The author should also make sure the proposal is in line with the values and mission of The Graph. This may include reading past blog posts that allude to The Graph’s design philosophy such as Horizon, as well as talking to existing contributors to The Graph. You can access the GIP 0000 template Here
Proposals can be submitted by forking the repository and creating a Pull Request to include the proposal in Markdown format, following the GIP-0000 template.
Discussions around proposals should be directed to the GIPs and Governance category of The Graph’s forum. To avoid conflicts in GIP numbers, proposals should be posted as a Pull Request on GitHub with a GIP number before being posted to the forum.
Publishing a GIP does not guarantee inclusion in the protocol. Protocol upgrades are implemented via decentralized governance, while the GIP Process is geared towards surfacing and building legitimacy for valuable protocol upgrades that can be considered in that process.
After the author has followed the process described above, the proposal has been discussed in relevant calls, and the changes have met the requirements to be ready for deployment, the proposal can advance to the Candidate stage. At this point, the author can request the Council to discuss the proposal for acceptance by filling in this form
In addition to this high level overview, a GIP Process guideline has been provided below.
This guideline is a list of suggested actions anyone thinking about submitting a GIP can consider throughout the process of bringing their submission into existence. It is not mandatory or an exhaustive list of actions you can take. It is intended to help authors of GIPs if they ever find themselves stuck and need some direction. Click on the summary of any section for a detailed list of actions you can take to help keep your proposal moving.
GIP Process Guideline
(For Informational Purposes Only)
Research
Summary
- Research the forum for previous related discussions
- Look at existing work or the state of the art to study feasibility at a high level
Getting Started with GIPs
Summary
Socialization, and Community Feedback
Summary
-
Socialize your proposal across multiple venues. Post your idea to:
- The Graph Forum
- The Discord Community
- X (formerly known as twitter)
- Discuss your idea with active contributors to The Graph’s Repo
-
Gather and integrate community feedback from all social media venues
Determine if:
- Initial consensus from the community is positive or negative
- The idea is technically feasible
- The idea has been proposed before and was not successful
- The idea is in line with the mission, vision, and design philosophy of the graph
- Consider withdrawing your proposal if consensus is not positive. If consensus is positive continue towards implementation
Proposal Enhancements
Summary
- Continue to add additional information or complete your proposal on GitHub
- Iterate on the GIP based on the discussion on The Graph Forum
- Include a link to your Graph Forum page on GitHub
Profile your ability to implement the Proposal
- Determine if you will be able to implement the proposal on your own and if you will be able to arrange for a security audit if required. If not:
- Request support from the Graph Foundation
Profile the nature of your Proposal
- Determine if your proposal will require off-chain software changes. If so:
- Submit a pull Request to the corresponding Repo
- Collaborate with Core Developers of that Repo to address off-chain items
- Determine if the Technical Advisory Board will be required to review any changes
- Determine if any off-chain updates impact the Feature Matrix or the Arbitration Charter. If so:
- Obtain Explicit Council approval to make changes
- Determine if your proposal will require smart contract changes. If so:
- Create a pull request against the code base where changes are proposed
- Integrate feedback from Core Developers
- Review changes with the Technical Advisory Board if required
- Obtain clear communication from the Council that the GIP will be moving forward
Enhanced Socialization and Community Feedback
Summary
- Build out your GIP presentation materials
- Consider creating a community poll on proceeding with your integration. Allow enough time for community members to participate
- Present at appropriate community forums - whichever are relevant to your proposal
- Present at Core Developer Calls
- Present at Indexer Office Hours
- Update the The Discord Community of proposal enhancements
- Update X (formerly known as twitter) of proposal enhancements
- Continue to discuss your idea with active contributors to the The Graph’s Repos
- Integrate any feedback, work to answer any open questions, and remediate any deficiencies until positive consensus is attained
Proposal Implementation
Summary
- Develop the implementation of your proposal
- Work with Core Developers as required
- Obtain Security Audits (for smart contracts related proposals)
- Create Test Plan and Staging (for smart contracts related proposals)
- Document test steps in a spreadsheet, notion or some other documentation method
- Ensure test plan covers the main changes of the proposal & the most relevant edge cases
- Create Automated Test scripts
- Seek feedback from Core Developers
- Create the Deployment Plan (for smart contracts related proposals)
- Document release steps in spreadsheet, notion document or other method
- Ensure you specify the transactions that must be run, and any relevant off-chain actions that must be taken to deploy the GIP
- Ensure council transactions that can be batched together are identified
- Collaborate with Core Developers on Deployment plan if required
Council Vote to Approve & Implement
Summary
- Fill in the intake form for the Council to vote on accepting the GIP
- Review council feedback and integrate any changes that may be required
- Check in on Snapshot for the outcome of accepted GGPs
Final Implementation
Summary
GIP Author, Core Developers, & the Technical Advisory Board work together to deploy the accepted GGPs