A passionate plea to separate content from communication, and keeping a centralised source for announcements

[remie]

As mentioned in this and that thread, and also on the Atlassian Partner Portal, the Atlassian Marketplace team will be taking steps to turn feedback into action with regard to content & communications.

This is primarily the result of feedback from Atlassian Marketplace Partners regarding the (ab)use of CDAC for announcements, discussions, documentation, release notes, cloud incidents, etc.

Looking at the proposed actions, I really applaud the team for looking into which medium / format is best suited for each different form of communications. Critical cloud incidents should indeed go into a (public) service desk. There should be a chronological overview of changes per product in a change log. Architectural changes should be documented in Confluence, which supports versions that allow vendors to see the latest up-to-date implementation details but also review how it changed over time without having to search for separate topics or go through lengthy threads in a discussion.

Obviously, CDAC could/should still be used for discussions (ngl, I’m not looking forward to having lengthy discussions in Confluence).

But… there is one thing that I find somewhat disturbing from the current plans, which is the fact that not only the content is being moved to separate (and more appropriated) sources, but also the communications.

In the current plans, announcements will move together with the content to the new place. For product changes, this means that announcements will be communicated through a newsletter, a blog post or just through the change log. This means that I will have to keep track of three different sources per product.

In addition, some content will move to the partner portal, which means that I will have to track notifications from Confluence to see which pages changed. Which does not always work if restrictions are used during draft editing to keep a page private and the page gets “published” by removing these restrictions.

For Marketplace Partners, we are moving to a situation in which there are going to be N number of places to track for announcements (Partner Portal, change logs, DAC blogs, email newsletters).

It is currently already really hard for partners to keep on top of everything Atlassian Marketplace Partner related (and I know because I’m curating the #remiebot channel in the partner slack workspace which got me the Devotee badge on CDAC just because I check every day for new announcements).

So here goes my passionate plea: it would like to ask the Atlassian Marketplace team to consider separating content from announcement. Please do move all the content to the appropriate places, being either Partner Portal, DAC blog posts, change logs, whatever. But make sure to create a single place (whether this is CDAC or not I don’t care) in which all teams post their announcements.

I understand that this creates an extra burden on each of the Atlassian teams, but please do take into consideration that from a DX perspective it would really improve lives for Atlassian Partners. Otherwise, you will be placing the burden onto us to find relevant information often required for us to succeed with your platform.

PS: one argument to consider keeping CDAC as the single source for announcement is because a lot of partners have automated scanning of RSS feeds to make sure they keep up to date, as a result of Atlassian saying CDAC would be the single source of truth. Moving away from that would mean a lot of vendors needing to update their scripts to include all these different sources to get the same overview.

[amardesich]

Hi @remie Thanks for the feedback and suggestions. Let me share some of our thinking on these.

• CDAC could/should still be used for discussions - We agree and lean more towards ‘Should’. One of our primary goals is to restore CDAC to it’s original purpose of the community getting answers and having discussions. We think comments in Partner Portal are better used to get specific questions answered about the content or to make requests/give general feedback about the content. There’s even a page on Partner Portal where we try to give tips on how comments should and should not be used.

• Announcements will move together with the content - this is what we’re thinking, but we’re also not trying to create any new sources. We’ve been using partner portal blogs for communications over the years and some partners have to follow it anyway since they are also Solution Partners. The Developer Blog and Developer newsletter are already in place and have been for some time. So while we intend to move communications away from CDAC the goal is to eliminate 1 source you need to monitor, not add additional sources.

• Challenges tracking content changes in Partner Portal This is an area we need to do some work on. There is the ability to watch a page, but you’re right it doesn’t work when Atlassian’s post in a draft space first or publish without notifying watchers. We’re working on some of these, for example having Atlassian’s publish copies of their content vs. moving content between spaces so alerts are triggered. But also having stronger communication in general to make sure that when important content changes are made, those are promoted in our communication vehicles such as the Ecosystem Skim newsletter on Partner Portal so you don’t have to work as hard. We’re also going need to work on how you can follow collections of content more easily since you can’t watch a label at this point and we are using the same spaces for all content on partner portal at least at this point in time.

I hear you on having a single source for communication. One of the things we have to consider is our developer audience aren’t all Marketplace Partners. Some messages are confidential only to partners, or only impact partners with paid apps. So as we go foward the different channels of communication help us optimize for audience segmentation. Developer blog and Developer newsletter are public for everyone, Partner Portal is specific to partners. There are going to be announcements and topics that will need to be covered in multiple communication channels because they apply to multiple audiences. If we do this well, you may find that even though we use multiple channels you can rely on just one of those. I can’t promise we get it perfect in the first round though.

It sounds like the biggest concern is the alerting mechanism(s) used more so than the channels themselves. I’d love to learn more about what you and others have built or relied on for alerting so that we can see how we might replicate or find new solutions for those. If we’re going to create gaps, then we definitely want to explore how we can bridge those until we can build something better. If you’re open to it, we should arrange a call so I can understand your current process for tracking and getting alerts.

The ultimate goal is to improve communications for partners and we will need to continue iterating based on feedback every step of the way so please keep the constructive input coming!

[remie]

@amardesich thank you for your elaborate response!

Personally, I don’t use any automation or alerting mechanisms. I open CDAC multiple times a day, scan the new threads “since last visit” and share those on the Marketplace Partner slack channel.

Up until recently, this worked pretty good. Obviously I don’t know what I missed by only tracking CDAC, but in general, much of the content from other sources was also shared here. For instance, @rchu has been great at making sure content from newsletters or Partner Portal were also posted to CDAC. In case I missed something that was not posted on CDAC, other Marketplace Partners would share those. In the past, those additions were limited.

That is also why I think this is not a correct analysis:

@amardesich

We’ve been using partner portal blogs for communications over the years and some partners have to follow it anyway since they are also Solution Partners. The Developer Blog and Developer newsletter are already in place and have been for some time. So while we intend to move communications away from CDAC the goal is to eliminate 1 source you need to monitor, not add additional sources.

This is exactly what I mean by trying to separate content from announcement. Yes, there has always been multiple sources for content. But up until now, there was also an effort to create another single source for announcements. By removing CDAC as a source, instead of eliminat[ing] 1 source you need to monitor, you are effectively removing the one source that allowed us to stay on top of things.

To give you an example: it was only because @MaggieNorbyAdams posted a message in the informal Atlassian <> Partners Slack workspace that many became aware of the Appy Hour campaign. With previous campaigns, such as ApptoberFest, this was also shared on CDAC. The campaign itself was documented on the partner portal, but the announcement was done on CDAC. That way, you had a lot more reach.

Again, I don’t really care about whether you are using CDAC or not. I’m also fine if you create a single page on the Partner Portal that is updated each time with an announcement. Or a completely new tool. As long as the announcements are aggregated and separated from the actual content.

Because, knowing myself, I’m pretty sure that I won’t be able to keep checking all these different types of sources and I will get lost in all the different types of notifications. My inbox is already a hellish place that I tend to avoid. I might at some point invest time in coming up with a way to aggregate all these different sources to a single location.

But until then, if you continue with the current plan, I will be less informed compared to the current CDAC solution. I’m pretty sure that this also applies to a lot of other Marketplace Partners, and I hope they will also share their feedback to give you a better understanding of the impact.

[james.dellow]

@amardesich is there no way that you can’t automatically cross-post to different channels so we can choose where we keep track?

[amardesich]

Thanks, @remie I now understand, that you personally are the ‘Remiebot’ This is great feedback and there are definitely things in here we can use to improve plans and/or bridge gaps if we might create with change. Things like:

• Dedicated page on partner portal aggregating partner portal blogs intended for Marketplace Partners and also for page updates or new pages specifically targeting Marketplace Partners.

• Cross-posting to CDAC that something new is published somewhere else for longer than we may have originally planned.

Being less informed is not going to help us improve the sentiment of our partners, so we’ll definitely continue to refine and balance using channels partners are telling us would be better with the ultimate goal of ensuring our announcements actually reach the audiences they’re intended to without making it harder on Partners in the long run. Any change is hard in the initial phases until we all get used to a new normal, but we don’t plan to launch and move on when it comes to communication and announcements we will continue to iterate and fine-tune to make improvements. Communication is at the heart of a lot of areas of frustration across how you all work with Atlassian.

[amardesich]

@james.dellow Yes although in the early days we might just be managing it manually to make it happen. What you’re describing is the ultimate goal. If an announcement needs to reach both a public developer and partner audience, it needs to be in multiple channels which would mean that the channel we use specifically for partner-facing audiences should have everything that the public-facing channels do at least when it comes to things that meet a criteria of must know or need to know. We may not replicate every nice to know or tips and tricks type announcement because it could get too noisy and with things that aren’t meaningful to you. Right now we have 4-5+ primary communication channels: CDAC, Developer Blog, Developer Newsletter, Partner Portal, emails, and then also some slack channels, changelogs, etc. We’re not using all of these as consistently as we should, so part of this exercise is to clean things up and trim down the sources of communication so that we create more consistency in how they’re used and where we cross-post so that things are easier for you all to follow and get the information.

We’re working on new processes internally and bringing together groups that currently run these different channels so we can get better at this. We will need to think about how we package some of these things up so it’s not overwhelming also. For example, in the Ecosystem Skim monthly blog on Partner Portal, we’ve tried to use short hyperlinked ‘In case you missed it’ call-outs back to CDAC posts or something we know already went out in another channel rather than completely repeating all of the content. On bigger announcements that we know we can’t afford to have anyone miss, the right answer will be replicating content completely in each channel.

[remie]

@amardesich maybe we can find a solution that is mutually beneficial. I don’t necessarily mind helping out and creating an aggregated & curated “all things Atlassian” space. I’ve done the same in the past with creating an aggregated overview of current release versions of Atlassian Server/DC products (see https://iapetus.fyi)

However, I might need your help to identify all the sources, and in some cases this might require a bit more collaboration to get it right.

The change logs and developer blog are easy to automate as they all have RSS feeds and they represented a structured chronological list of items/articles. CDAC also has RSS feeds but needs a bit more curation. That is also something I can do myself (import automatically, only post when approved).

Developer Newsletter / other emails are more difficult. I can subscribe to newsletters with a specific address, import those and thread them similar to CDAC posts with manual approval. But I would need to know which emails to track. Do you have a list?

The biggest hurdle is the partner portal. I guess I can poll the Confluence API for that site using a personal access token, and use CQL searches for lastModified and again do a manual review of the results and see if it should be published? Or maybe you can add a announcement label that I can track? And perhaps you might even be open to install a Connect app (sorry, we’re not yet using forge) on the Partner Portal Confluence site to allow webhooks instead of polling?

Are there any other sources I’m missing? And does this sound like something Atlassian could (unofficially) support / condone? I’m fine with open sourcing the solution and opening it up to collaboration with other vendors / Atlassian.

[kmorales]

@remie Can you elaborate on what you mean by “CDAC needs a bit more curation”? The original intention behind the many “announcements” categories was that it would allow everyone to only subscribe to the categories that are relevant to them. The thought was that putting them all into the one Announcements category would be too much noise/not enough signal, but perhaps I’m wrong there? Would love your thoughts on this as I’m putting together the project plan for the work @amardesich mentioned.

[remie]

@kmorales Ok, so this is going to be my personal experience with CDAC and notifications combined with my personal preference with regard to notifications. I don’t know how other people work with CDAC or what they prefer.

The #1 reason for “noice” within CDAC is the fact that it is basically a thread dump of everything. It includes discussions between metal tier partners, in-house developers, one-off API users or end-users that are posting on the wrong forum, combined with the fact that it includes all types of (development) and partner topics (Jira/Confluence/etc, Cloud API, Server/DC API, Hardcore P2 framework, Forge CLI, Connect, security, systems operations, marketing, MPAC, etc, etc, etc).

This results in an endless stream of messages. Not all topcis that are of interest for Atlassian Marketplace Partners are strictly announcements. In addition, not all announcements are marked as announcement.

My curation involves the simple question: what topics do I think are relevant for Atlassian Marketplace Partners. That can be both announcements, but also technical or marketing / MPAC related discussions.

I post each of these topics into the #remiebot channel in Slack (which currently has 75 members), and occasionally cross-post them into a specific channel (for instance, #forge, #security, #connect, etc). For the current month, there have been 24 topics that have been shared in the #remiebot channel, whilst there have been 382 posts (visible to me) on CDAC in that same period. My curation is not infallible, and occasionally other people also post topics in the channel that I’ve missed or misinterpreted.

The idea behind announcement categories is great in theory, but in practice it does not work out for everyone, for instance:

• because not everyone has configured which categories to follow
• because not everyone knows how to configure that
• because they miss the email notification
• because they have the email notification on daily/weekly digest
• because they did not know that they were also interested in category X they were not following
• because the message was not tagged / tagged incorrectly

The reason that I started this curated list is because the only way I’m 99% sure I’m not missing anything is to read everything all the time. Which means that I check CDAC multiple times per hour (except when I’m sleeping) to keep the “Since last visit” list manageable. Usually, my cross-posting from CDAC to Slack happens within 15-30 minutes after the post got online.

I’m not saying this is the best or only way to manage announcements. And to be honest, I actually agree that CDAC is not the best place for announcements because of the sheer volume of other messages on this platform. With that low volume of announcements, they get easily buried in random questions (like, how to use the unsupported Python REST API wrapper).

What I’m trying to convey is that for most Atlassian Marketplace Partners, having a single source to look up those 25-50 announcements per month that are relevant to them for running their business will make their lives a lot easier. And I know that you are trying to cater to a greater community, but I think that this small subset has, over the past 10 years, generated 1+ Billion reasons (and counting) to have earned a bit of a special treatment from Atlassian.

[paul]

For me #remiebot is fantastic. I know if anything comes up I’ll know about it. It is my daily go-to place for announcements.

[david]

#remiebot is actually the most helpful announcements mechanism for the ecosystem at present. Think of it like the ~monthly ecosystem skim, but updated daily+

I don’t envy the poor soul who is reading every post.

The amount of email notification noise I get from CAC, CDAC & PAC is insane and I easily miss stuff because it’s just too much & also there are relevant things that I might not have have subscribed to or even know about.

When comms and documentation are mixed up in a CDAC thread with over 100 comments, knowing what the actual current correct documentation is, is almost impossible.

[amardesich]

Hi @remie sorry for the delayed response we’ve been discussing your last post here.

1. Any sources missing: We have been talking about how and when we use the Developer Blog along with the other sources you mentioned (Changelogs, Developer Newsletter, Partner Portal Blog). This discussion will help us refine our strategy on how each channel is/should be used and when we need to use multiple. We will be publishing a page that outlines the primary sources and how we use them over the next few weeks. So once we have that out we’ll probably all have some more to react and spar on.
2. Working on ways to create feeds or consolidated places to check for updates across channels is definitely something we support and condone. The exact solution is something we’ll need to think through and test. Ideally, I’d like for Atlassian to own that and really drive improvements, but if we don’t have a good enough solution then we definitely need to work on backup plans such as open-source options or maybe a longer transition timeline than we had originally planned.

[remie]

@amardesich I agree, it would be great if Atlassian would create & own the aggregated place for all things Atlassian in terms of announcements. But please do not hesitate to make use of the large Atlassian Marketplace Partner community that is willing to help you.

For some reason, Atlassian has never been keen on using community resources, whether it is bug fixes for AUI, AJS, Connect JavaScript library or AtlasKit, or even contributing to documentation. This to the frustration of the community, as we are well aware that Atlassian does not have the resources to fix every bug, or cater to every request.

There seems to be no strong open source advocacy within Atlassian, which means that you are missing out on the willingness of the eager and engaged community that you’ve built to help both Atlassian and ourselves to succeed. I hope that we can avoid making that same mistakes again. Please make sure to always remember that there is a helping hand reaching out to you while you continue discussing and planning how to best organise this.

[remie]

@amardesich not meant as a digg, but as an example:

Introducing Content State API is an announcement that has been wrongly categorised. Anyone following the announcements RSS only would have missed this.