DSNP

Specification Development Process

Version: Draft 2024-03-19

Your comments and feedback on our Specification Development Process are warmly welcomed and greatly appreciated as we strive to grow together as an open-source community. Please send governance/process feedback to: dsnpfeedback@projectliberty.io

Introduction

The Specification Development Process plays a pivotal role in the governance of the Decentralized Social Networking Protocol (DSNP). By establishing clear roles and responsibilities and a structured workflow toward publication as a released specification, the process supports transparency, openness, and community engagement. It is aligned with the DSNP Mission and Principles.

Roles and Responsibilities

• Chair (or Chairs) take overall responsibility for progressing work, setting meeting agendas, and calling for decisions, adjudicating disputes, and determining consensus. Chair(s) may delegate work while retaining overall responsibility. Chairs are chosen by the spec development group. DSNP Steering Committee can hear appeals.
• Editor(s) are responsible for the text of the specification. Their selection is confirmed by the Chair(s).
• Contributors: Any person who [agrees to the terms of the DSNP Agreement, including its Code of Conduct and IP policies (being developed at the moment of the publication of the spec development process)] may contribute to specification development.

Steps

1. Initiation

Anyone in the community can identify the need for a new feature in an existing specification or a new technical specification by raising an issue on GitHub or in a Public Meeting. Discussion on the GitHub issue will help gauge community interest and potential directions. Participants are encouraged to enumerate use cases and requirements at this stage.

2. Specification Drafting and Editing

Editors draft the specification in a GitHub repository. Any Contributor may offer pull requests with proposed additions or changes. These should link to discussion of the rationale and support for the proposed change. Chairs or Editors may bring the discussion to a Public Meeting for further input or may merge or reject the pull request based on the online discussion and approvals from at least two previous committers.

3. Public Meetings

Chairs schedule and conduct public meetings to discuss the draft specification, building the agenda from issues and pull requests in GitHub repositories and other requests for discussion. Stakeholders can participate to provide insights, raise concerns, and propose improvements.

4. Pre-Release Specification

Chairs issue a public call for review, bringing the draft Specification to the community at a Public Meeting and in a GitHub issue as a release candidate. Chairs should seek review and feedback from stakeholders who would be affected by the Specification’s changes. Chairs retain the authority to stipulate a specific minimum duration for the release candidate stage and establish a deadline for reviews. Nevertheless, the standard time frame is generally set at approximately 30 days.

5. Release and Distribution

Upon determination of rough consensus, Chairs release the “Published Specification”. Rough consensus does not mean unanimity, but comments and feedback should have reasoned responses.