[@yenda](https://github.com/yenda) has written a comprehensive description of the [Status communication protocol](https://docs.google.com/document/d/1Qh2h07T_qepzEJ7IytmxwIdQAOsGHrvhXwZxuZtbwgc/edit?usp=sharing) which will be externalized for the public to read.
We will also leverage @yenda’s doc to create a miniseries of Whisper-focused content for our marketing channels.
Great documentation is necessary to position Status as a platform for Ethereum developers. Supporting content will establish Status’ POV on the use of web3 technologies and ensure visibility of our docs.
We'll use @yenda’s Status communication protocol as the basis for our first polished piece of technical documentation under supervision of our technical writer @alexm.
In tandem we’ll draft a proposal for a miniseries on Status’ communication protocol and use of Whisper. The full series should outlined, drafted and published in the scope of this swarm.
An idea for the miniseries topics from @arnetheduck:
- General introduction to Whisper and its relevance at Status
- Description of various messages and payloads used in Status chat
- How we achieved our massive bandwidth reduction through Whisper v6 + payload experimentation
- [Challenges and ideas for the future](https://docs.google.com/document/d/1Cw3LA1r6ItLDp8bMFvIxQMxYjnzEVOcHuZJz8gRa7HE/edit?usp=sharing)
Status core team engineers will be required to write the miniseries content, to offer depth of technical perspective. Ideally one team member will author each post, for review by the other authors.
This project also acts as a means for the marketing team to experience swarms in practice. Marketing will help to inform the miniseries strategy—content format, channels, etc.—and coordinate visuals.
## User Stories
Non-core team developers want to learn about Status’ use of web3 protocols.
Non-core team developers want to work with Status’ messaging protocol.
## Requirements and Dependencies
[UPDATE TK: doc system swarm]
The miniseries is not dependent upon the publication of our protocol documentation; this work can happen in tandem, but should be delivered before the final iteration. It’s important that we have technical documentation for readers to explore further.
We’ll also require graphs and visualizations to bring the protocol to life. One great potential example is [@divan](https://github.com/divan)’s [data visualization work](https://github.com/status-im/ideas/blob/123-visualization/ideas/123-whisper-visualization.md).
## Security and Privacy Implications
## Dates
By May 7th, we should have a clear strategy for the miniseries, with contributors identified and an outline of the story, as well as clearly identified work for publishing the communication protocol.
By May 21st, we should have the first part of our miniseries completed and ready to publish.
## Minimum Viable Product
Goal Date: 2018-07-05
- Decide on a topic outline for the Whisper miniseries
- Write an outline for each part of the miniseries
- Identify and begin sourcing potential supporting graphs and visuals
- Determine work needed to publish Status Communication Protocol: copy-editing, missing information, etc.
## Iteration 1
Goal Date: 2018-21-05
- First part of miniseries completed and published
## Iteration 2
Goal Date: TBD
- Second part of miniseries completed and published
## Iteration 3
Goal Date: TBD
- Third part of miniseries completed and published
- Whisper Communication Protocol documentation published
## Iteration 4
Goal Date: TBD
- Fourth part of miniseries completed and published
- Propose guidelines for writing future technical docs
- We receive positive feedback on the miniseries from our community.
- Each part of the miniseries receive X number of social shares.
- The documentation receives X number of page visits within 3 months.
## Exit Criteria
All 4 parts of the miniseries are published and the refined Status Communication Protocol doc lives online.
Status documentation is easy to find.
We have guidelines for writing and structuring future documentation.
## Supporting Role Communication
Outside of this swarm we are setting up an open-source documentation system. Embark team is also in the process of building a website for their documentation. These work streams should be aligned and may also delay or impact work on the communication protocol.
All core teams should be aware of the new documentation process and be encouraged to document any work in progress as thoroughly as possible.