You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
I see that a question was recently closed because it was an announcement, and to be honest the tone used didn't really suit this forum.
However, I am interested in hearing about new plugins and new versions of plugins, at least from the developers. I know we have discussed this before and IIRC the result was that Atlassian said they were going to modify PAC to allow banners and announcements or something.
But, and this is the contentious bit of my question, do we want to give up editorial control and allow them to "feature" banners and announcements according to their business plan?
Not to get too weepy but none of my plugins have ever been "featured" on PAC despite one of them being in the ten most popular list. Out of interest I hit the feature plugins page 100 times and below (click expand source) you can see a histogram of the numbers of plugins featured. There's a disproportionate list of commercial plugins (fair enough, suits their business model for other companies to make money out of jira) and a disproportionate number of Atlassian ones (also can't blame them for that), and it doesn't look very random either, what with the Codegeist winner getting most impressions. Therefore, if you're a smalltime opensource guy, I can't see you getting that much of a look-in.
In summary, personally I am happy to see announcements here providing they are not too sales-y and tagged correctly.
**************** Scroll Wiki PDF Exporter (16 times) ************** Template Bundle: Human Resources (14 times) ************* JIRA Plugin for Salesforce or SugarCRM (13 times) ************ Go2Group JaM Plugin (12 times) ************ JIRA Importers Plugin (12 times) ************ Ad hoc Workflows (12 times) *********** Atlassian Bonfire (11 times) *********** Bamboo Release Management Plugin (11 times) *********** GreenHopper (11 times) *********** Content Formatting Macros (11 times) ********** Balsamiq Mockups for JIRA (10 times) ********** CustomWare Scaffolding Plugin (10 times) ********** Composition Plugin (10 times) ********* Documentation Theme (9 times) ********* Rate Macro (9 times) ********* Bamboo Artifactory Plugin (9 times) ********* Team Calendars for Confluence (9 times) ******** Bamboo Tomcat Plugin (8 times) ******** JIRA Bamboo Plugin (8 times) ******** SharpView High-Resolution PDF Viewer for Confluence (8 times) ******** Scroll Office (8 times) ******** Bamboo iOS, Cocoa and Xcode Support (8 times) ******** Community Bubbles (8 times) ******** Structure (8 times) ******** Numbered Headings (8 times) ******** JIRA Email This Issue Plugin (8 times) ******* JIRA Bitbucket Connector (7 times) ******* Worklog Assistant (time tracking) (7 times) ******* Tempo Plugin - Time Tracking and Billing Management (7 times) ******* Builder Theme (7 times) ******* Enterprise Tester (7 times) ******* JIRA Charting Plugin (7 times) ******* Gliffy Confluence Plugin (7 times) ******* Appfire's 'Niko-Niko' Team Mood Calendar for JIRA (7 times) ****** Flowdock for JIRA (6 times) ****** CustomWare Reporting Plugin (6 times) ****** BugDigger for JIRA (6 times) ****** Zen Foundation (6 times) ****** JIRA Calendar Plugin (6 times) ****** Go2Group synapseRT (6 times) ****** Flowdock for Confluence (6 times) ****** SQL Plugin (6 times) ***** Bamboo SCP Task (5 times) ***** RefinedWiki Mobile Interface (5 times) ***** JIRA Workflow Designer (5 times) ***** Page Approval Plugin (5 times) ***** Atlassian Universal Plugin Manager (5 times) **** RefinedWiki Original Theme (4 times) **** JIRA FishEye Plugin (4 times) ** Template Bundle: Software Development (2 times)
You can't currently see the histogram due to https://jira.atlassian.com/browse/ANSWERS-279, but if you're interested then edit this question.
Jamie, you're right. But Answers should provide spaces ("rooms") for announcements and other spaces for plugins. This will keep things tidy.
Just my 2 cents.
In this respect, Answers enforces a bad usage pattern. If the user does not label correctly the question, sometimes you do not know even what Atlassian product s/he is talking about. So what can we say then about plugins?
Anyway, I'm speaking as a developer who does not expect too much revenue from the plugins; we do not care too much about prestige, either. I can understand that things may be seen in some other light from another perspective, and this is why Atlassian should roll out a version of Answers with REAL support for plugins and their users.
Jive provides a capability to mark a discussion as a question in order to easily identify the difference between discussions that require a response and those that are more for kicking-the-can around a topic. Being able to mark a discussion in Answers as a question, I think, would go a long way to solving this need. Then there's no need for separate "spaces."
I thought about voting this question up, and I struggled with it a little bit. The problem is that the Plug-ins space (https://plugins.atlassian.com/plugin/home) isn't built for an active community of engagement in the same way this space is evolving. I would vote up improvement there, or an evolution of this space to meet the simultaneous demand of supporting "discussion topics" in addition to "I need help" questions (preferred).
So... in resolution to my own internal conflict, I'm voting up this topic.
The thing about discussion rooms is that I don't want to have to subscribe to every room to hear about a new plugin or that someone's written a new blog... OTOH I'm not averse to a short announcement "question" here providing it's not written in marketing-speak or contains the words "special offer".
I think what I'm trying to canvas for is allowing announcements here, but as Beth said, some ability to mark it as "not a question".
The linkedin suggestion is valid but then equally it could go on twitter or facebook, but I don't use any of those things, just this forum.
The guide doesn't really seem to address the question, it seems more about what content to include in your marketing rather than where you can centrally announce your product's existence or new features to the JIRA community. The Plugin Exchange is all very well if you already know about the plugin's existence and want more information but I'd quite like to keep an eye on updates and new plugins without having to subscribe to every possible social medium and plugin vendor's blog just in case they announce something of relevance to JIRA.
I'd like to subscribe to JIRA plugin announcements and I'm not fussed where they are! I personally use LinkedIn so I'd see announcements made to the JIRA group but unless everyone uses the same place you're not going to be able to reach everyone that way.
What's the problem with having an 'announcement' tag in Answers? It would clearly mark a post as an announcement and anyone who didn't want to see announcements could ignore the tag. Maybe you could limit users to say one announcement a month or make it cost karma to keep volumes manageable and prevent over/mis-use. If it cost karma then plugin developers like Jamie and Radu who contribute a lot to the community would be able to afford more announcements (and would probably have something more relevant to say anyway) - karma in practice!
Or possibly the Plugin Exchange would make more sense to hold plugin-related announcements. Would it be possible to create an Announcements page there for plugin developers to make announcements (by product if possible)? Either way the fact this question keeps coming back indicates there's a gap which is yet to be satisfied.
Thanks for the well thought-out comment.
the fact this question keeps coming back indicates there's a gap which is yet to be satisfied.
I've also been coming to this same realization since it's not only plugin developers! Atlassian developers are wanting the same thing. All right, let me see if we can put our collective heads together and figure out a good way to tackle this problem. We have PAC, we have Answers, and we have the Altassian subscription center (my.atlassian.com/email). We'll need to think through the best spot and how it should work.
I agree wholeheartedly with J Thomas. The Plugin Marketing link above is directed squarely at commercial plugin developers, and is so off the mark with respect to the original question that I've not been able to summon the energy to respond til now. I don't want to bombard people with social media messages, nor be "awesome, kick-ass, or go out on a limb", I just want to let people who may be interested know about something new in my non-commercial plugins. Let's just use the announcements tag for now, if people don't like it they will downvote.
I too am interested in hearing about new plugins and updates to existing ones. One possible way to do this (and keep in mind I am not endorsing anything, just to provide a workaround), is to post it in the JIRA (or Confluence) group that is in Linkedin. I've seen other announcements for commercial plugins come out from time to time. I know that community is not nearly as big as this one, but it may be one way to get more notice.
Again, I am not endorsing anything and this suggestion is something that can be taken or not. Its just my two cents.
If an user finds a third party tool which it would be useful for many Atlassian customers but it's not formally a JIRA nor Confluence plugin (so it cannot be announced at Atlassian Plugin Exchange).... can it be announced at Atlassian Answers?
It's a real case.
I know is forbidden to publish plugin announcements in Answers. Of course, Atlassian is studying an alternative....
Since days ago, Atlassian announced OnDemand and they encourage companies to move to the Cloud. On the other hand, they closed OnDemmand for most plugins. Only a small pre-selected group can be installed. Atlassians do it because... security? and likely a lot of additional reasons.
If you learnt mathematics at school then you will know that: 1+1=2: They banned most plugin developers from Answers and now from OnDemand too.
They did not "ban plugin developers". They just tried to quieten a lot of noise being made about plugins when they weren't relevant because they were detracting from the current question or thread. I agree with the principle - if I ask a question about "growing strawberries", I don't want a long conversation about "tractors for fish", it's not useful. If a discussion abotu a plugin is relevant, then it continues.
I really do want to see a better place for discussions about plugins directly, and I'd like to see it even-handed - I really don't care if a plugin is written by a sprawling conglomerate or by someone tinkering part time. As long as it solves a problem or improves something, it's worth talking about.
And yes, I can see the logic in tying down OnDemand - I've had clients happily saying "we want plugin X" and then realising it exposes security flaws. Letting any old plugin in is not a good business model, you have to be responsible and that means thinking carefully before letting any 3rd party stuff in.
I think Pablo's point is that the advertised reason that plugins are blocked is security, yet the requirements are not clear, and clearly there is more to the process than security alone. It's all rather opaque. Of course everyone wants their plugins to get the largest installed base, yet they can't take everyone's plugins, so perhaps it would be a benefit if they could make it clearer what their selection criteria are.
BTW, I don't personally have a beef around this, none of my plugins are suitable for OnDemand. My beef is just about "banning" announcements here.
Here is Atlassian's Security Policy: http://confluence.atlassian.com/display/Support/Atlassian+Security+Policies
Here is Atlassian's development support documentation: https://developer.atlassian.com/display/PLUGINFRAMEWORK/Writing+Atlassian+Plugins
I don't develop plug-ins and can only report as a consumer who has to run her instance of the application through very heavy third-party security screening, but I would think that it would be reasonable to expect that if any plug-in causes a vulnerability that it should be excluded from an onDemand product, and ideally reported as carrying such in the plug-ins forum for those who download and install it to their instance. If you do not feel that documentation is thorough enough that Atlassian provides, then likely you should log a request. There's an option to provide feedback at the bottom of the second link above.