Prepare and store our newsletter.
Similar to the Rust community's, we want to have a newsletter that talks about what was done in the past week by various contributors. This will help:
- Keep people in the loop about what is going on at Protocol Labs and on IPFS.
- Tell active contributors when new versions or tools are available.
- Attribute developers who have contributed to open-source software related to IPFS.
The Newsletter takes a lot of work. This work can best be done by being distributed. If you know of anything cool that happens in a given week, anything that other people might be excited about, add it to the newsletter by adding a comment about it to the PR or Issue for that week's newsletter.
Here are the steps to do that:
- See something cool, or make something cool.
- Go to the open PR for that week's newsletter.
- Add a comment about the thing. Add a link, if possible.
- Revel in the knowledge you are great.
Also, please help us out if you think the roundup could be better! Open an issue!
- Stores the final versions for past newsletters, posted elsewhere - the blog, email, and so on;
- Tracks issues related to the roundups in the issues;
- Stores tools used to make the roundups
- Open a Pull Request to create a new Markdown formatted file in the
publishedfolder. The naming format should be as in this example:002-2016-jan-5.md, for the newsletter of the sprint starting January 5th in 2016. - Collect feedback and iterate on the draft.
- Images
- Add files into published folder
- Add using
-wto ipfs - Use ipfs.io gateway to add files in
- Merge it after:
- Sign off from pertinent people
- The travis build for the branch completes after each push.
- Crosspost
- ipfs/ipfs#151
- the Blog
- The IPFS Tinyletter, using
md2htmlnpm package to generate HTML - Twitter: post the blog link after it is merged and published.
- Use people's GitHub handles and not their real names. Example: @RichardLitt, and not "Richard Littauer".
- Try and include everyone who has made a PR or commented on an issue. Often, issue comments are major, pivotal contributions, and those should be captured!
- Highlight, don't just summarize; a lot of work may be trivial, and higher signal is better noise.
- In general, err on the side of giving credit to everyone involved. When people do the lion's share, mention them first. (Or even something like "@whyrusleeping and several others ... " if relevant. In the case of a release, you can link to the changelog which credits individually... but don't sweat this.)
- In general, try linking larger phrases instead of single words. They're easier to notice and click on links.
- In general, try highlighting why something is cool. Call attention to things if
- it is done and people should know about
- there is a call to action -- opinions are needed.
- it is specially useful to draw attention to something in the newsletter.