A healthy community is propped up by a handful of key components: shared values, a desire to learn, clear guardrails for participation and, perhaps most importantly, an environment where members feel welcome to share their questions and ideas.
Think of voice as a constant, a personality that doesn't change. Tone, however, is a mood, which adapts based on who you're talking to. When interacting with other members, your tone may change based on where someone is at in their journey (novice vs. expert) or what product they're using (Bitbucket vs. Trello).
In that spirit, we’ve compiled a list of real examples from the Atlassian Community that exemplify the voice and tone we encourage all members to adopt in order to create a space that keeps folks coming back for more! The goal is to be aligned with Atlassian's own internal rules, which are led by three principles: bold, optimistic, and practical, with a wink.
What the Atlassian Community is
-
Optimistic
Example thread from @Meg Holbrook:
-
“I love that you all did your own Summit - it looks like it was a great success! This is such an awesome idea.”
-
-
Inclusive
Example thread from @Mary Ramirez:
-
“Glad to have you back! I think a buddy system is a great idea. Especially if you become friends for life. Makes me think about how beneficial this would be to a newbie. I remember feeling uncomfortable asking my new boss my 100+ questions. But having a senior or native employee to partner with and bounce ideas from sounds more comforting.”
-
-
Empowering
Example thread from @Thomas Schlegel:
-
“Hi Michael,
Pages in your Confluence are sorted alphabetically by default unless you start to sort them manually. Then the latest page is added as the last one in the tree.
You can restore the default sort order by clicking on the "A-Z-arrow" again:”
-
-
Helpful
Example thread from @Cameron Eldridge:
-
“General
-
Make it a habit of clicking the Calculate button every time you navigate back to your plan. Data may have changed while you were away.
-
Create a page template in your Confluence space to capture requirements for each Initiative. This will help ensure everyone has a good grasp on the scope of these big work items.
-
You can link these directly to your Jira issues.
-
-
Create an Initiative kanban board to track the progress of high level Portfolio items.
-
You can also create an Epic kanban board to show which Initiative each Epic is linked to.
-
Include the Parent Link field on the board's Card Layout to easily see parent Initiatives.
-
Committing Plan Changes
-
Try not to leave an abundance of uncommitted changes in your plan. Hundreds of uncommitted changes can make it difficult to remember everything you adjusted if you haven't visited your plan in a couple of days.
-
Ensure changes made in one scenario don't overlap with changes in another scenario. Otherwise, you may end up with conflicts that prevent you from committing changes.
Issues sources
-
Scrum teams should use boards as their issue sources to take advantage of their sprints and associated history.
-
Portfolio can calculate a suggested velocity for each scrum team based on the story points completed in previous sprints.
-
-
When using a single issue source in a plan with multiple teams, Portfolio often schedules work for the "incorrect" team. This is especially prevalent when teams don't have any members assigned to them.
-
Leverage the Portfolio Team field in your issues to avoid scheduling conflicts.
-
Share your plan's private teams so that you can designate them in Jira issues.
-
Of course, you'll need to add the Team field to all applicable issue screens.
-
-
Alleviate scheduling conflicts even further by creating a unique issue source for each team in your plan.
-
-
Multiple Scenario Planning
-
Create at least two scenarios for your plan.
-
Ensure that one of them, such as "Live," always reflects your Jira data in its current state.
-
-
Title your scenarios based on their purpose.
-
Examples
-
Live
-
Sandbox
-
Grooming
-
Best Case
-
Release Shift
-
-
Plan Permissions
-
Avoid giving too many users edit permissions of your plan. Committing changes back to Jira can be very dangerous.
Scheduling
-
Apply default estimates to unestimated work items to get them to show up on the timeline.
-
This is most helpful when used in Epics and Initiatives that don't contain any child issues.
-
-
Pay attention to the ranking of stories in your Backlog. Rank holds the most weight in Portfolio's scheduling algorithm.
-
Estimated issues not assigned to sprints will automatically be placed in fake, placeholder sprints (e.g. Sprint 1, Sprint 2, etc.) that only exist in Portfolio, especially when ranked low in the backlog.
-
As a result, the plan may appear to be overbooked. Re-rank those issues higher in the backlog, then assign them to a sprint if the overbooked schedule doesn't revert back to green.
-
If the schedule is still red, overbooking may be present elsewhere in the plan.
-
-
-
-
-
Solutions-oriented
Example thread from @Nic Brough _Adaptavist_:
-
“Good plan. But I'm afraid it's not as easy as it should be.
There are loads of types of field in Jira as far as we humans are concerned:
-
System fields that Jira always has on issues. There are four broad groups of these
-
Structural ones that are not really fields - Project, issue type and status.
-
Non editable fields - created, updated
-
Mandatory system field - summary, resolution (ok, resolution is not mandatory, but you should treat it as a field you always have to think about, whatever your users say about how much they don't want to use it)
-
Optional system fields - assignee, reporter, environment, due date, comments
-
Note that applications and add-ons can add to those - Service Desk, Software and Portfolio will add things like Epic Link, initiative, request, yadayadayada
-
-
Custom fields
However, the only system field I would bother analysing is "environment". The others are either too useful to get rid of, or you can't.
So, to answer question 1: Go to Admin -> Issues -> Custom fields. That's the list of fields you want to look at (and tack "environment" on to the list)
Question 2:
For each field, run the JQL "<field> is not empty". This will return a list of all the issues with content for that field.
This does not tell you a massive amount though. I find it far more useful to save each one as a filter, then go to a new dashboard and add a "filter statistics" gadget, using "project" as the statistic. This way, it tells you the number of issues using the field by project. Far easier to read, and can lead you to "hey, you guys are the only people using this field, how about we rationalise it" conversations.
Question 3:
Not hugely, but it can make searches a bit more frustrating for a user, if they assume that a field they see in their project exists in someone else's project.
You won't get any technical gain from hiding fields, it just simplifies some of the views for users. If you want to make things a bit faster, change the field contexts, so they only belong to a sub-set of projects and/or issue types.”
-
-
-
Empathetic
Example thread from @Jack Brickey:
-
“Welcome to the Community. I'm not sure about your deleted post TBH so can't directly comment on that. As you may be aware the Community is largely comprised of users just like yourself, this includes me. I clearly get your frustrated and would like to see if there is anything I, or others in the Community, can do to help. I don't know that I can change your overall perspective on the tool as a whole or the company I would like to think maybe the Community can help w/ specific issues you may be having. If not then certainly reaching out directly to Atlassian Support might resolve the issue. With that said is there a particular issue w/ the product that you seek assistance with?”
-
What the Atlassian Community is not
-
Condescending
-
Passive agressive
-
Confrontational
-
Promotional