@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.