Blog Content - Peer Review

[Bruno]

Currently, to publish a post on the Status blog, one needs to be given permission to post to Ghost and then share a draft link with people who might be interested. This is a manual process which sometimes accidentally excludes people who might want to contribute in some way. There’s also the barrier of having to find the person to let you into our publishing process, which isn’t easy or practical for anyone. In order to increase transparency and a feeling of community on non-confidential publications, I propose an open source peer review model.

1. We set up a repo: status-im/writing or something of the sort.
2. Anyone interested in contributing a post forks the repo and submits a post in their own folder with a PR.
3. The folders have a fixed structure, like this:
   
   
4. This content is then up there, open source, with a label auto-applied “needs review”. Other labels exist such as “needs more content”, “needs language help”, etc.
5. A review is anything from typos to content and ideas for changes
6. Once a consensus has been reached on a post that it’s in publishable shape, it can be put online

Reviews work similarly: fork the repo and submit edits as PR to PR, or (arguably simpler) just put comments onto lines you think should be modified / removed / fixed.

Advantages

• a transparent review process, all out in the open
• the ability to reward the most active reviewers with SNT (e.g. top peer reviewer in October) or to find external contributors for hire (an outsider consistently active on our posts, submitting fixes or writing content might be a good candidate). Additionally, NFTs (badges) could be built to support this and add flair to our contributors - it’s vanity decoration, but one people tend to like a lot (I’m one such person, every aspect of my life is badgified really). I believe such a gamification of content review would be very appealing.
• a collaborative effort keeps everyone in the loop about pending and incoming topics, and lets the community and newsroom folk have a better overview of scheduling needs
• we can attach bounties on draft topics - “build an NFT with Embark”, “use Studio to debug a contract”, “optimize a dapp for performance tutorial”, all those are awesome tutorial ideas that we could throw out there and offer to people. Many aspiring writers simply have no idea what to write about and I end up manually suggesting topics when I manage such teams. A “for grabs” list such as this one would increase engagement, build the community, and reward contributors (say, $100 - $200 per post in SNT would be a good bounty for good tutorials, but payable only once peer reviewed for okayness).
• in time, this might turn the Status publication into a nice repository of quality blockchain-related technical content, helping the project with increased visibility, spreading education, and helping new aspiring writers with their careers.

Disadvantages

• it adds a layer of semi-bureucracy to the publishing process which will turn some people off
• it requires the use of Git which some people are not comfortable with

Note that a hybrid approach might be optimal here in which we test drive this for a while, see how it works out, but keep the old model for the “instantly allowed to publish stuff” people.

Examples:

I have implemented this process previously in two different publications with great success.

• SitePoint’s Peer Review - our engagement went up tenfold, and visits increased dramatically, though I have no figures to share, it’s been a while.
• Bitfalls Peer Review - does not work as well when the team is small and incentives are lacking, or when the project is a side-gig like this one. However, this one had a nice experimental twist - the metadata you see in the image above contains the ID of the post in the WP database. This made it possible to accept a PR to a post (e.g. a correction) in Github and have the post’s render in WP auto-update, so we didn’t even have to use WP after a while, and we could change to a different CMS easily. Github served as our own headless CMS there, in a way. Additionally, this model supports multi-language publishing because Bitfalls’ audience is primarily US and Croatia.

[exiledsurfer]

Posting to ghost is currently only for status core contributors, and invited WOT community members. It is permissioned permissionlessness. It is highly unlikely that this will change for the url our.status.im. Yes, it is exclusionary, for now - for hitting the publish button on a post. One of the reasons is the code injection feature on headers / footers of individual posts. We cannot open up that attack vector.

Our.status was not created for “anyone” to post to, it was created for core contributors (and by extension, trusted community members) to post to without going through the bottleneck of review by marketing or founders.

If you want to “collaborate” with others pre-publication, this could be a good method if you want to use this, and other people want to use it, that’s great. But following this should not be a requirement for core contributors to post to our.status.

The whole point of our.status was to eliminate exactly two bottlenecks:

-collaborative / editing / approval of posts by marketing or founders (now you are shifting it to peers).
-non github users having to use github to collaborate on posts.

There is also no automation in pulling a github file into a ghost post. (though that could possibly be scripted, or a zapier plugin be written that would be available through the ghost admin dashboard)

If this type of pre-publishing collaborative editing works for you for and others, you should use it - i can imagine this is great for tutorials, as you entail. - but we won’t be opening up our.status for “anyone” to publish on anytime soon.

Collaborative editing with external contributors can also be done on notes.status or hackMD. No one is being excluded from creating / collaborating, just from Publishing.

What i could imagine is that we create a user name specifically for collaborative posts from the community that you manage with this process, and one would only have to add attribution / link in the body of the post.

[Bruno]

Okay, was not familiar with the permission structure, good to know.

@exiledsurfer

-collaborative / editing / approval of posts by marketing or founders (now you are shifting it to peers).

True. There could be a “default” period wherein if a post is uncommented for 2 days it’s automatically approved or something, but I do agree that at this stage the current method works well and is in an if it ain’t broke don’t fix it mode.

Maybe we’ll open a community tutorial center one day and use this there.

[exiledsurfer]

i think what you want to do is a good approach for the developer segment of our community, not trying to discourage you at all ! Especially after the comments that came in from other devs after you published the first post. But that points out the problem with collaboration - the people who notice mistakes AFTER publishing, and point them out, usually are hard to motivate to collaborate pre-publishing. It’s not like you hadnt asked in slack for commentary / corrections prior to publishing…