If you’re new to the documentation team, you may be wondering how we operate on a daily (or weekly) basis. Below are some of the processes our team follows.
Standups
Our team meets on a daily basis for standup to discuss where we are at in our individual projects and prioritize the day as needed.
During standups, we communicate the following:
- What you did yesterday
- What you plan to do today
- Any blockers that might prevent items from getting completed
Standups typically occur over video call, but feel free to drop a text standup in the team-docs Slack channel if you are unable to make the meeting.
Triage
Each week, team members rotate monitoring incoming documentation requests and pings in #org-documentation. Our triage process helps you understand how we prioritize documentation requests.
Retrospective
We host a team retrospective every Friday to discuss the past week. These meetings are largely informal discussions about what our team did well and what we could improve on in the following weeks.
Retrospective topics often fall into the following categories:
- What we did well this week
- What we didn’t do well this week
- Other team-related comments on improvements we’d like to make
With each item that needs improvement, we discuss and come up with an action to be taken in order to prevent a solution from falling by the wayside.
Managing Issues
During Monday’s standup, we do a sweep through the Jira board’s Backlog category to determine our workload for the week. Here, we prioritize issues and assign them to team members. The weekly prioritized issues will then end up in the On Deck column to indicate that they’re ready to be started.
Once you begin with an issue, there are 3 columns in which you can move the card to represent its current state:
- In Progress - the issue is currently being worked on
- Needs Review - the issue is complete but needs peer review
- Done - the issue is complete, has received peer approval, and can be merged into the repo’s
masterbranch
Pull Requests
Once a draft is complete, we open it up for peer review with pull requests. Pull requests allow for other Banno team members to provide feedback, request changes, and approve your doc. Once two approvals have been received, you should be good to merge it into the repo’s master branch!
Service Desk Rotation
Each week, a member of our team will be assigned to the request service desk rotation. This is a lightweight activity that simply involves triaging requested documentation from the service desk to our documentation board prior to Monday’s sweep.
How we use Slack
A lot of our quick asynchronous communication happens in Slack through channels and direct messages.
Channels can be thought of as a group chat regarding a specific topic, like a team or product feature at Banno. The documentation team has two Slack channels dedicated to it:
team-docsis a private channel involving just the documentation team members.org-documentationis an open channel for any Banno team member to discuss the organization’s documentation. Any posts from other channels tagged with the:documentation-team:reaction emote will also be cross-posted into this channel. This is mainly used to alert us to documentation that needs to be updated.
For more information on best practices in slack, please see the communication guidelines page in the wiki.
How we use Stack Overflow
If an individual notes a Q&A has not been documented or should replace incorrect info within an existing doc, they should tag the doc team (DocMods). The documentation team will then review and prioritize the request, so we can make the changes as soon as possible.
Individual doc team members will also filter through Q&A’s to add or update content on the Knowledge Base.
Once you’ve taken info from Stack Overflow and published it on the Knowledge Base:
- Comment on the Q&A thread with a link to the article: This content is added to the Knowledge Base here.
- Add the
added-to-kbtag.
How we write
Since we are a team of individuals, it is important to define a consistent tone, posture, and voice in our writing. See our style guide for more details on how we keep this consistent as a team.
Working on the Knowledge Base requires specific steps and guidelines. For those, see our Banno Knowledge usage guide.