Hej Atlassian,
Thanks for introducing the RFC system. I have a quick question though: can you please stop writing RFCs for changes to the Atlassian Marketplace?
Given that you are just not going to listen to partner feedback (beyond perhaps changing a comma here and there), you might as well spare yourself and us the effort of writing the RFC and commenting on it.
Cheers,
Remie
I share this frustration but I think it’s a couple of RFCs that have come across that seem to want to be able to say that “we asked the vendors and they said ok” which is coloring my view.
It might be useful to get a RFI (Request for Input) for things that are way down the line and less flexible to be changed.
I will raise my request that if Atlassian wants the RFC process to be succeful - every RFC should have a survey at the end which is then published back to the RFC.
In addition to the survey request, we also need to know what was done with the survey results.
We also need an escalation path, and Atlassian should come up with a policy for teams that indicates at what point an RFC has enough vendor feedback that work should either be postponed or halted.
I mean, if you look at RFC-26: New Roles and Permissions System for Marketplace, you basically have feedback from the likes of Appfire, Tempo, Adaptavist and other Gold & Platinum Partners telling you that the RFC is not good enough.
If feedback from this group isn’t even significant enough to change course, then Atlassian should tell us what is??
Same with voting for features to be implemented. Votes are there, some tickets received hundreds of them, yet the status would be “Gathering interest” or “Won’t implement”.
@remie whilst I can empathise with your frustration that feedback is not always addressed or incorporated, this post is not an effective way to advocate for change.
The RFC program is designed to facilitate collaboration between Atlassian teams and the developer community. It is not perfect, and we are intending to iterate on it, however I can not commit to a timeframe for doing so as the small team of intrepid Atlassians who built the RFC program are currently prioritising other endeavours to improve the quality of life for you and your fellow developer community members. We are aiming to share some more about these at Atlas Camp, but in the meantime I would ask for your patience.
I would however like to set expectations that it is unlikely that the RFC process will ever be one that “binds” Atlassian teams to any specific course of action. The developer and partner community are a stakeholder in the projects that impact them, but there are always other constraints and business pressures internally that need to be factored into any particular decision. It is not always possible to publicly share the internal factors impacting the outcome of an RFC.
I share this frustration but I think it’s a couple of RFCs that have come across that seem to want to be able to say that “we asked the vendors and they said ok” which is coloring my view.
@danielwester I can assure you that we do not use the mere existence of an RFC as a “rubber stamp” to indicate that the community approves or disapproves of a change. We are attempting to get teams to publish RFCs earlier in the design process, but as the RFC program itself is in a fledgling state this is not always possible. Our current philosophy is that feedback is still better sought later in the R&D process than not at all.
I would also say that comments on RFCs, even if not immediately incorporated, are useful in that they are structured feedback that can be used to advocate for you internally. Past comments on CDAC have been routinely used internally to share insight into partner sentiment towards particular topics, sometimes long after they were originally posted.
We also need an escalation path, and Atlassian should come up with a policy for teams that indicates at what point an RFC has enough vendor feedback that work should either be postponed or halted.
Again, it is unlikely that we will implement a process that compels a team proposing an RFC to take any specific action as the result of feedback. While we believe partner feedback is an important input into the R&D process, there are always other internal factors at play, and sometimes those factors can unfortunately preclude incorporating important feedback into a design in a timely manner.
While there is no formal method for escalating an RFC, I would recommend engaging with the RFC, politely raising constructive feedback or “liking” feedback that resonates with you, and (when the RFC recommends) using any outreach methods recommended by the RFC author. If you are a large enough partner to have a dedicated partner manager or technical contact at Atlassian then I would also recommend escalating critical concerns via them if you feel like you are not getting enough traction on an RFC.
Same with voting for features to be implemented. Votes are there, some tickets received hundreds of them, yet the status would be “Gathering interest” or “Won’t implement”.
@dmitry.astapkovich like RFCs, feedback left on public issue trackers is similarly subject to internal constraints and prioritisation. While product managers will often consider the number of votes or comments on an issue as a signal of interest or importance from the community, there are always other factors that influence whether it will end up on the roadmap.
It might be useful to get a RFI (Request for Input) for things that are way down the line and less flexible to be changed.
I will raise my request that if Atlassian wants the RFC process to be succeful - every RFC should have a survey at the end which is then published back to the RFC.
@danielwester I appreciate your constructive feedback here, and we will endeavour to evaluate better ways to set expectations when soliciting feedback and for measuring outcomes of individual RFCs when we iterate on the process.
On a final note, the RFC process is voluntary from both the perspective of the developer community and the Atlassian teams that participate in it. @remie while you generally have valuable insights to share, the manner in which you deliver that feedback is increasingly making it difficult for it to be ingested and actioned by well-intentioned Atlassian staff and/or championed internally by Atlassians in external-facing roles such as myself. If you do not find value in RFCs related to particular topics, then I would encourage you to abstain from participating in those topics.
The problem is we never know the reasons and other factors. Therefore, it’s a one-way street, and basically you are asking us to act nicely on anything Atlassian does or just keep it to ourselves. Btw, communication with the dedicated manager doesn’t work too, since it’s a) not public b) they have no decision making power c) there’s no clear mechanism except “escalating critical concerns”.
But you want us to shut up. Ok, so be it. I’m done with providing useless feedback.
Did anything ever bind Atlassian to do anything?
Like reasonable tickets that got dragged on for years, even decades?
Authentication for Automation web hook
https://jira.atlassian.com/browse/JRACLOUD-31953 (2013)
(Heh, guess we’re not using this now with the new limit)
Like all those pages of comments in this page?
(https://community.atlassian.com/t5/Automation-articles/Introducing-our-new-packaging-model-for-Jira-Cloud-Automation/ba-p/2446099)
@KCWong Reasonable tickets?
This one is now old enough to drive a car in some countries.
https://jira.atlassian.com/browse/CONFCLOUD-69222
@dmitry.astapkovich I honestly do not want you to shut up, and I tried my hardest to avoid sounding like I was trying to do some sort of PR / damage control in responding to this post.
The core message I want to convey is that ultimately the Atlassian staff members reading the feedback that is shared by the developer community in whatever medium are people, and that feedback that is polite and constructive tends to be much more effective at influencing them than feedback that is disrespectful, belittling, or sarcastic.
I do understand the frustration you must feel when issues that you are passionate about are not prioritised, and I do recognise that it must often feel like a one-way street. I do also realise that this is Atlassian’s problem to solve, and I continually strive for us to do a better job at supporting developers building on our platform. The feedback that I see from tenured members of our community on RFCs is typically poignant and high-quality, and it kills me that many issues (even critically important ones) can’t always be addressed before a feature is launched.
The ask I have for you is to try to keep it respectful. I and my team spend a significant part of our weeks lobbying teams to have better outcomes for partners. It is perfectly fine for feedback to be tough or poignant or impactful. I know the RFC process must be frustrating at times, but it has already resulted in delayed deprecations, major revisions to designs, or key decisions that have been completely reversed. Positive partner outcomes are far easier for us to advocate for when we have clear constructive feedback that demonstrates that the negative partner outcomes clearly outweigh the business imperatives driving a particular change. Feedback that is respectful and constructive tends to be much more effective and leads to more effective outcomes when we lobby teams internally, than feedback that is derisive.
Ha, challenge accepted.
https://jira.atlassian.com/browse/JRACLOUD-3821
Created in 2004, status is even “In Progress”.
Mr. Priority scheme, a member of Server / Data Center, but he went MIA on his way to Cloud.
The damage is done. It’s permanent.
I can empathise with your frustration that feedback is not always addressed or incorporated, this post is not an effective way to advocate for change.
It’s left unstated what is an effective way to advocate for change, or whether there even is one.
Well said. We’re a “community” and should all try to be respectful, no matter what our professional opinion on certain topics is.
I touched on it in my original reply, though it was a bit of a wall of text so understandable if you missed it 
:
While there is no formal method for escalating an RFC, I would recommend engaging with the RFC, politely raising constructive feedback or “liking” feedback that resonates with you, and (when the RFC recommends) using any outreach methods recommended by the RFC author. If you are a large enough partner to have a dedicated partner manager or technical contact at Atlassian then I would also recommend escalating critical concerns via them if you feel like you are not getting enough traction on an RFC.
RFCs are the best opportunity as the R&D team behind the feature is actively engaged and seeking feedback (or should be — as I mentioned above we are trying to get teams to use RFCs earlier and so be more open to significant changes).
Early Access Programs are another phase in the lifecycle of a feature where feedback is actively sought and more likely to be reviewed and actioned in a timely fashion. We’re currently working on improving Partner EAP processes to make them more consistent and effective across Atlassian.
In addition to RFCs & EAPs there are a few other channels you can try, depending on the nature of your feedback:
Of these options, the timeliness and quality of response you get from Atlassian on feedback will depend heavily on the topic and the timing. Currently only Incidents and Bugs reported via ECOHELP are guaranteed a response*.
Improving our RFC and EAP programs are a first step towards improving feedback mechanisms more broadly. I’m keen to explore more effective governance of other feedback mechanisms in the future, but we have prioritised these programs in the short term as timely feedback from partners on projects that Atlassian is in the process of designing or building tends to be the most effective at leading to impactful outcomes.
* Please note our Developer & Marketplace Support teams work extremely hard to try to turn around issues in a reasonable timeframe, so please ensure you’re only filing authentic Bugs and Incidents there, or it eats the support capacity for everybody.