Podcast: Play in new window | Download
Subscribe: Apple Podcasts | Google Podcasts | RSS
In This Episode
In part two of this three-part mini-series, we talk about Atlassian Verified Apps.
** Plugins/Add-ons are now called Apps.
Products
This episode focuses on the following products:
- All products.
Links
- Plugins are now Apps – Community
- Verified Plugins Program
- Atlassian Supported Apps
- Bitbucket Server 5.4 Release Notes
Episode Credits
This episode is hosted, produced, and music by Mark W.
Disclaimer
All thoughts, comments, tips, and best practices shared by the host and or guests of the Admins of Atlassian Podcast do not reflect the views of Atlassian nor do they replace procedures and steps officially provided in the Atlassian product documentation.
Blogscript
Wait, What Is This ‘Atlassian Verified’ You Speak Of?
Built for the marketplace, the Atlassian Verified program is a set of Atlassian standards that vendors are held to as customers consume their products. These standards are in place to help apps gather traction, ensure timely support and vendor reliability.
To become eligible for this program, vendors must submit an application and if approved, their apps will be marked with an ‘Atlassian Verified’ badge in the marketplace. See Atlassian Supported Apps.
What Are The Requirements?
Below is a table of requirements that a vendor must meet in order to apply and be approved for Atlassian Verified status.
| Requirement | Details |
|---|---|
| Sell at least one paid via Atlassian app | The Verified program requirements apply to paid via Atlassian apps. You must sell at least one paid via Atlassian app to become a Verified Vendor. |
| Your paid via Atlassian app versions are installed in at least 500 active instances | At least 500 actively used product instances must report installation of your paid via Atlassian app versions. This is measured by the Universal Plugin Manager (UPM), which reports actively used host products (like Jira or Confluence) that have your apps installed. |
| Provide documentation for all paid via Atlassian apps | Provide a documentation URL for all paid via Atlassian apps. |
| Provide a support URL for all paid via Atlassian apps | Customers should be able to access your support URL and see a clear way to get support for your app — file a ticket, email your support team, or other ways to contact you. Your support URL should be hosted under your vendor name domain. |
| Offer support at least 8 hours a day, 5 days a week in your local time zone for all paid via Atlassian apps | Support hours can be any time, relative to your local timezone. |
| Publish and adhere to an SLA statement | Publish and adhere to a service level agreement (SLA) outlining your support and service level terms, available via URL. Your SLA should include:
|
| Use an issue tracker like Jira to resolve and track customer-reported bugs and feature requests, for all paid via Atlassian apps | You don’t need to use an Atlassian product to track your issues, but some kind of tracker to keep on top of customer-reported bugs and improvement requests. |
| Provide Atlassian with 24/7 emergency contact information | Provide an email address and phone number to Atlassian just in case we need to contact you for emergency support issues, such as those involving customer data loss or downtime. This information will only be used by Atlassian and will not be shared with customers. If something goes wrong, we should be able to reach you via this contact information 24/7. This information will be verified when reviewing the application. |
| Your site, Marketplace listing, and support documentation is available in English | The documentation should be spell checked and easy to understand. |
See table and other requirements at Atlassian Verified Program.
As you can see, a lot of the requirements are set to ensure that you have support and that you have somewhere to go if you have issues with your paid app. The requirements are designed so that when you purchase an Atlassian Verified app, you know that you are covered in the support department.
Should Apps That Aren’t ‘Atlassian Verified’ Be Avoided?
Of course not. There are tons upon tons of great apps in the marketplace and I encourage everyone to try and use what fills their need. Even so, the goal for many could very well be to become Atlassian Verified but they need YOU to give them a chance. This is where you can get in on the cutting floor to become instrumental to the developer and help them build their product if they are new, especially if no one else does what they do.
When Should You Care About Verified Apps?
This was a question I’ve received at Atlassian User Groups when users were trying to figure out what verified apps were and why or when they should care about it.
The Small Team
When you are a small team or you have a small instance such as JIRA, you may be more flexible with the apps you install or try out. This is fine. I’ve been there. You have a ravenous base of users and they want to see what else the product can do. Your first stop is to the Marketplace to see what’s out there. You find your app and install. Everyone now loves you and gives you pats on the back. You are now their favorite admin!
The Enterprise
As your instance grows and matures your perspective shifts. You will now become more critical of what apps your user’s request. You will now become more wary of what apps you install. You ask yourself “Is there documentation?”, “Is the documentation good?”, “What is their support like?”
This is the point where many make the transition from being the hero to their users to being branded as “no fun.” When I made the switch, I was tightening my platform. I also needed to ensure that the apps that I was evaluating had good support behind it. And that is when I began to include Atlassian Verified as a recommendation in my evaluations.
Why not a requirement? If I made it a requirement, there would be very beneficial apps that I would have had to pass on. While keeping it a recommendation, I was able to weigh the other requirements and needs of the app higher should they provide more value.
In The News
Before we go, here are some updates that you should be aware of.
Bitbucket Server 5.4 has been released. In this new update, Webhooks has now been added. You can use Webhooks to integrate into other applications such as a build system to trigger new development builds once a commit is made.
Now, you can make team member contribution easier. 5.4 allows you to add a markdown file to your repository. This file will include your guidelines on how to work in this repository. Such as links to your best practices or team members page.
Lastly, the Support Tools plugin has been renamed to Atlassian Troubleshooting and Support tool.
Please, be sure to check out the release notes in this episodes show notes at adminsofatlassian.com or the very app you’re listening to.
Closing
Thanks for listening to The Admins of Atlassians podcast, I am your host, Mark Williams. Be sure to check out the show notes for links to all the information I talked about. If you are new, be sure to subscribe to the podcast in your favorite podcast app, if you are on iTunes, be sure to leave a review. Tweet us @AdmnofAtlassian.
Cheers
Leave a Reply