Diffgram Improvement Proposals [DIP] Reference

What is an DIP?

A DIP stands for Diffgram improvement proposal and is a document that aims to provide information to the Diffgram core team and community about a new feature, archiecture improvement or any other related improvement to the Diffgram platform. We usually use DIP's when we know the new proposal requires a lot more technical and product discussion and does not fall in the category of a simple bug fix or small feature on existing subsystems.

This DIP format was inspired on Ethereum's templates for managing their improvement processes.

DIP Rationale

The reason for the existence of the DIP templates is for collecting information from the community and the core team to get as much context on the technical requirements and architectural implications of a new feature. Although we want to incentivize using DIP's as standard for proposing most changes in the platform, it is only strictly necessary for changes that are core to Diffgram's current system architecture, product or business in general.

DIP Statuses

DIP statuses are managed on the labes in our github issue tracker. As the DIP evolves the author and/or reviewers will change the status to the most appropriate depending on the progress of the proposal:

• idea - An idea that is pre-draft. At this stage we consider the DIP author is still working on improving the general idea and trying to give a shape to the main intent of the improvement
• in_process - At this point the DIP is already created and ready for all Diffgram core team member and contributors for reading. Although still some changes can be made.
• review - An DIP Author marks the proposal as ready for peer review.
• inal - This DIP represents the final standard.

Template for a DIP:

Each DIP should have the following parts:

• Preamble & Metadata: this section just includes general metadata about the DIP. Things like the number, a shor description and author details. This can also be included in the title of the DIP and avoid this section if desired.

• Abstract: Abstract is a multi-sentence (short paragraph) technical summary. This should be a very terse and human-readable version of the specification section. Someone should be able to read only the abstract to get the gist of what this specification does.

• Motivation: The motivation has the reasons for the new proposal. Add any contextual, historical or technical context that can help the reader understand why this proposal is relevant and can benefit Diffgram as a whole.

• Specifics: This is the core of the proposal, here you can extend as much as you want on the technical details, product details, architecture requirements, security implications or any other aspect of the proposal. The main goal is to give all the context possible to the reader.

• Notes & Considerations: Any other extra notes or information that does not fit on the rest of the categories, it can include references to other docs, comments on the DIP or bullet point for any other idea worth mentioning.