If you missed any posts, find the whole month in reverse chronological order here.
Collaborating with so many folks on this project has been fun and challenging. The dev.to site is a fantastic place to share technical content but it does have challenges for collaboration. This post describes some of the challenges we had and what we did instead (or plan to address for next year).
- Use a project board to visualize work in progress.
- Establish the pipeline, how does work progress to done.
- Be adaptable to change!
- Encourage psychological safety so folks speak up when problems occur.
- Use multiple forms of communication for coordination and visibility within the team (Slack and Trello for example!).
- Tag posts with appropriate well-known tags for visibility.
- Ensure posts are part of an organization with multiple admins to support publishing on schedule.
- Set a specific time within a timezone for publishing rather than just a specific day when the project has international collaborators.
One of the challenges of collaboration for a "post a day" calendar is pre-planning the topics, and phasing the work through a pipeline. We ended up using Slack and Trello for coordination.
We created a card per potential topic, with columns to establish the flow of work from Potential Ideas to Published.
| Potential Ideas | Assigned Articles | Reworking + Rewriting | Drafted + In Review | Edited + Ready for Publication | Published | |-----------------|-------------------|-----------------------|---------------------|--------------------------------|-----------|
Having cards represent the posts, and movable to specific states gave us visibility on what needed to be prioritized. Other information was tracked within the card itself. The intended author was assigned the card.
Once a date was assigned we added that into the Trello card's title. This made it easy to organize within a column what work needed to be prioritized for editing and writing.
Each author had different methods of preferred feedback which was a challenge. Some folks preferred everything organized within the Trello card; others preferred direct messages in Slack.
Using a kanban board for coordination allowed us to handle issues that came up for folks. They could speak up about a delay, and posts could be reordered. What's critical about this step is that individuals have to feel empowered to speak up and say "I'm not going to make this date." Life happens, and having transparency around any issues helps folks execute on the overall plan regardless of any individual pieces. Having backup content available is also super helpful.
Using a kanban board allowed us to pull in new people throughout the month to contribute. We had one plan at the start of the month, and that morphed as more folks joined the project. Having the visualization helped keep the project on track while also enabling for change.
With pulling people in and rearranging topics, we added a process of updating the Slack channel with a weekly topic list with folks tagged to their upcoming article. This had a side effect of also increased visibility for folks who didn't use Trello.
Each author would tag their post with the appropriate well-known tags. This helps with the visibility of the article by putting the content where it will help the people looking for information on that topic. On the dev.to platform, we're limited to 4 total tags.
With the series feature we can tag posts to be part of the "Azure April" series in the front matter. Series are tagged to an individual so if multiple people have the same series title, it is a separate series for each of them. To have a single place to point to we needed to create the azureapril tag which also meant limiting our post tags to well-known tags by 1.
With the Microsoft Azure dev.to Organization, more than one person had administrative privileges to edit and publish content of individual authors. With content ready and queued up to be published, even if the author forgot to post for a day, someone could publish the post.
One thing that was challenging is timezones. With folks participating around the world, days overlap. Having a feature that allowed us to schedule a specific time to publish would alleviate this, although we could have figured out some process external from dev.to as well that allowed us to publish on a specific schedule.
We're looking forward to working with the dev.to team to improve the collaboration and coordination of a project like this.
Thank you to the additional authors who contributed original content to Azure April:
I'd love to see more folks trying out these "post a day" collaborative projects. If you've managed one or participated in one, what tips and tricks do you have?
Were there any Azure topics that you'd like to learn more about that we didn't cover or subject areas we should dig more into? Do you have Azure tips and tricks you want to share?