This post may serve as a valuable aid for DGC Members seeking to author and publish their very first DIP document in line with Dijets Improvement Proposal Framework. Note that this post is not meant to replace the foundational principles outlined in the genesis document DIP0. Instead, the idea is to present the information contained in DIP0 which is the key to authoring DIPs, in a more user-friendly format, emphasising the necessary actions required by DGC Members and consolidating useful resources to navigate the proposal process effectively.
Before we dive into the finer details of writing and proposing a DIP, let’s briefly review the basics of Dijets Improvement Proposal Framework. And we can start with a generalised definition of DIP i.e What exactly is it and what is its purpose?
Quick Overview
DIP is the abbreviated form of “Dijets Improvement Proposal”, a design document which provides information about Dijets. The collection of these design documents forms the dynamic body of regulations/principles/instructions that govern Dijets Ecosystem and its primary domains. This information can range from describing a new feature for Dijets to describing any of its processes to introducing an idea that benefits the ecosystem. These features, processes or ideas are concisely specified within a DIP to act as the formalising document.
DGC Member or the authoring member that puts forth the DIP is responsible for building consensus among other members and for documenting dissenting opinions.
Dijets Improvement Proposal Framework provides a standardised way to write these DIPs. It establishes a standardised approach for:
- Writing a DIP
- Submitting the DIP
- Subjecting the DIP to scrutiny by the rest of the council.
- Voting on the DIP.
Templates
Proposals are built on top of templates and there are a number of these templates each serving a distinct purpose. Which template to choose for your DIP depends on the type of document you are creating. In most of the cases, the general DIP template should suffice.
The General DIP Template can be used to cover most of the general aspects of Dijets Ecosystem and its Domains. Whereas the Technical DIP Template should be used to modify the technical aspects such as the smart contract code or the codebase for the wallet etc.
Subproposals must use the template specified in the DIP that describes the particular process being instantiated. As an example take DIP0m11: If you want to propose yourself as a DIP-Editor, you will find that the process for that is defined in DIP0, more specifically in DIP0m11, and that the process specifies that you must use this template as the basis for your subproposal.
Github
Dijets Proposals live on a GitHub Repository in sync with Dijets DIPs Directory. Github is a code hosting platform for version control and collaboration built on git, a version control software. When DIP-Editor stores the proposals with their current status on Github, it automatically sends a notification to all of Dijets governance backends that a new proposal was added by the dips editor and the interfaces are updated with the new proposal details.
Its not important for DGC Members to know much about Github or its inner workings as most of the interactions with Github will be done by the DIP-Editor. It is enough to think of GitHub as a cloud storage service, and of repositories as cloud drives.
Github has its own set of commands and apps that users can interact with. Luckily, as I said before DGC Members are not required to know about Github in detail. DIP Editor will gladly take care of that part for you.
How do I start?
As a DGC Member if you think you have an idea for a proposal and you think it’d be a good idea to check the council’s appetite for it. And you are ready to get the proposal going through its lifecycle but you do not know how to go about bringing that idea to life in the context of Dijets Governance and DIPs then the following info will help you.
Below is the DIPs Lifecycle detailing the process for each stage and whats required. Let’s see how as DGC Members you can start with your very first DIP.
1. Conception
This is the very first DIP lifecycle stage. It starts with the conception of the idea behind your proposal. During the Conception stage your proposal will receive the council’s feedback that you as the authoring member should use to refine it. Think of this stage as the exploratory period when you are trying to gauge the council’s collective appetite for your idea and whether it has legs. The proposal idea doesn’t need a format at this stage and you can basically post about it just as if you were beginning a new topic of conversation on the forum. There are two requirements to transition from this lifecycle stage to the next lifecycle stage. (Note: An email detailing how to post a topic under the Sentiment Check category was sent to each member)
- A rough draft of your proposal idea needs to be posted on the forum right here, under the Sentiment Check category.
- Your posted topic on the forum needs to be up for a minimum of 48 hours before progressing. In these 48 hours the rest of the DGC members can ask you general questions about it or ask you for clarification on something they are unsure of. (This is a great opportunity for members to earn LQs. The more questions and genuine requests for clarification a member asks for, the more the chances of earning the LQs increase.)
2. Accepted by DIP Editor
Once the idea has been up on this forum’s Sentiment Check category for more than 48 hours and the council has asked and received questions/clarification about it, the authoring DGC member can go ahead with sending the proposal idea to the DIP Editor. Members will need to send the proposal in the right format to the Editor. That means having picked the template General DIP Template and filling it out with the necessary details and then sending the document to the Editor via email, Qowalts or messaging here on the forum. The DIP-Editor makes sure that the proposal meets the DIP framework standards before progressing it to the next stage. There is one requirement to transition from this lifecycle stage to the next lifecycle stage.
- Authoring DGC Member’s comment under the proposal post stating Submitted to DIP-Editor for Review
3. Request for Comments
DIP-Editor labels the DIP with a number and adds the status tag in the preamble of the DIP. The Editor then publishes the standardised format DIP on this forum under the RFC category and adds it to Github Repo by submitting a pull request. Request for Comments or RFC is the last opportunity for DGC Members to read through the DIP after it has been converted into the standardised format and before it proceeds to the next stages. Members are free to ask further questions or for clarification at this stage on the forum. There is one requirement to transition from this lifecycle stage to the next lifecycle stage.
- A comment by each DGC Member including the authoring member stating DIP#(number assigned) CAN PROCEED TO FORMAL SUBMISSION. (Note that the comment will need to be made under the post in the RFC Category and not the Sentiment Check
4. Formal Submission
The DIP Editor and the Team prepare the Polling Document for the proposal by selecting the correct template. The Editor updates the proposal’s status in Github to Formal Submission via PR officially adding the idea to the governance portal queue for allocating the proposal a voting date. There are no requirements for the proposal to progress at this stage. The Governance Portal does its job autonomously and adds it to the queue for voting when its time.
5. Voting Cycle Begins
The Governance Portal publishes the poll for voting. Members can choose to vote for or against the proposal.
6. Voting Ends and Results are published
At the end of the voting period, the winning option is declared. If the proposal reaches the minimum threshold of 10K HAL, DIP-Editor marks it as ACCEPTED and the implementation cycle for the proposal begins. If the proposal can’t reach the minimum threshold of 10K HAL, the Editor marks it as REJECTED and doesn’t progress it any further.
DIP Status
Following is the list of the DIP statuses the Editor will update the DIPs with during its lifecycle. Status change is updated through a pull request on Dijets Github repo.
| Status | Status Name? | When is it assigned? |
|---|---|---|
 |
Proposals with RFC status are currently going through their Request for Comments Lifecycle stage. |
As soon as the DIP-Editor posts the DIP on the forum DIPs > RFC Category. |
 |
Proposals with Formal Submission status have been submitted by the Editor to be voted on the Governance Portal. |
After a proposal has fulfilled any transition requirements. As soon as the DIP-Editor posts the DIP on the forum DIPs > Formal Submissions Category. |
 
|
Proposals with either of these statuses have had their Approval Polls run on Dijets Governance Portal | At the closing of the voting period. |
This post should serve as a good starting point to help DGC Members walk through the steps necessary to submit their first proposal ideas into a form that is compatible with the DIP Framework. Please remember that the processes you read and learn and even help build are there for the rest of the world to see and be able to trace back to their inception and implementation along the way.
DIP-Editor
I am really pleased to confirm that Alisha has now been onboarded as DIP-Editor thanks to the council voting in favour of DIP0m11SP1 through Voting Poll She is very well suited to handle the editor responsibilities. I am sure that once she’s gone through a few governance cycles she’ll be up to speed with any questions, queries the members will have regarding the DIPs process.
| DIP Editor | GitHub | Forum |
|---|---|---|
| Alisha | DijetsAlisha | @DijetsAlisha |