Feature Policy - Communication Schedule

[David Meredith]

NOTE: I'm not actually sure where this should go, so please move to an appropriate place if needed.

I don't think I'm alone here but the issues at jira.atlassian.com can feel like like a pretty hopeless place.

It's worth bearing in mind that each admin that votes could represent hundreds / thousands of agents and users who are impacted by the functionality gap. Still these represent a small proportion of users impacted. Many organisations just don't have the time or motivation to track > 100 ~5 year old issues on top of their day jobs.

Anyway, seeing a feature request gathering thousands of votes over 5-10 years with little or no update.... Is demoralising and justifiably makes the community (paying customers) feel ignored and unimportant.

Even a note to say that a feature "isn't being developed right now due to other priorities and will be reviewed again in X" is better than the deafening silence.

I'd like to propose a simple communication schedule to the 'Feature Policy' to set some expectations to the community around when they're likely to get an update. 

• <   500 Votes (Issue Unassigned) - Nothing
• >   250 Votes (Issue Assigned) - Annual Update
• >   500 Votes (Issue Unassigned / Assigned) - Bi-Annual Update
• > 1000 Votes (Issue Unassigned / Assigned) - Quarterly Update
• > 5000 Votes (Issue Unassigned / Assigned) - Quarterly Update + Progress

I feel like this would be achievable and would start to rebuild some bridges with a community that regularly jokingly return to their favourite feature reqeust each year to laugh at the rage of the new customers finding it for the first time.

EXCLUSION: Everything I've seen assigned to Simon Herd has had some excellent community engagement! This could be looked to for good practice.

I think I feel a little better now... How do others feel about this? Is it something Atlassian can consider? How is it best to get this kind of change?

Dave

[Nic Brough -Adaptavist-]

I'm broadly with you.  JaC has always felt under-used by Atlassian product owners. 

I do know that they do pay some attention to it, but it is only one factor in their planning and design, and very much feels like it's always been the least weighted factor, because so little of it gets looked at.

Voting in Jira doesn't really work.  It does on a small scale, where it's one organisation, but JaC isn't much use.  An issue that has 500 votes weighs the same as another with 500 votes, but it does not capture that one of those issues has been voted for by 500 10-user licence holders and the other by 500 10,000-user licences (so the second one should be ranked far higher than the first).  

That is rather an over-simplified example, in real life, the 10,000 user licence instances are likely to have other routes - they're likely to be engaged with a partner and/or have an Atlassian TAM, both of whom can shout louder than the little guys.  We (partners) and TAMs are way higher on the input list than JaC is.   

I think Atlassian should move most of this to JPD, which is designed to gather feedback and improvement data, rather than JSM's support model and JS's development model.

JaC is also very old (heck, my first issue in there is still recorded, and the issue key only has 4 digits, not the 6 we see now, but got fixed by some helpful chap called something like Michael Bombard-Streams?) and it's not well-curated, it's been half-heartedly redesigned a few times, and hence is riddled with unloved,  twisted, and in some cases, just simply damaged, data.

I would love Atlassian to pay more attention to it.  But not with the voting system it uses now, and certainly not the current workflow, which feels designed to leave us in Limbo, not telling us what is actually being done.  (I'd prefer to be told "you're being ignored because this is way too low on the list" than "gathering interest").  

I do understand it though.  The product owners at Atlassian have many sources that they are required to consider when ranking their fixes and improvements, it's just not great for we end-users that JaC is a) low on the list and b) huge - there's an overwhelming amount of things in it, old and new.

Part of me thinks that if I were to part with Adaptavist, I'd like to take a job as a Jira product owner.  But I would be terrified of it - I don't know that I could cope with the volume, and I'd fear that I would just get bogged down in updating JaC for the customers (I'm a grumpy old man, I struggle to be nice when I want to write "no, that's a stupid idea", although I'm quite good at explaining why I said it)

[David Meredith]

Hey Nic,

Thanks for your response! You can probably tell I'm in my grumpy old man mood too!

I appreciate that the product owners and developers are most likely going to be focussed on developing new features and products that are going to generate more revenue / customers. But then those new customers are going to use the shiny new functionality and then find that there is still basic stuff missing / not working from 10 years ago.

I think the reason I find communication on these boards so important is that this is where you end up after you've spoken to Atlassian Support and they're unable to make the product work like you expected it to. So unless they start pointing users to JPD instead I think they need to commit to some kind of communication schedule to set some expectations.

It can be looser than what I suggested above but knowing that there will be an update within a timeframe would cut out a lot of the frustration. It might even incentivise the community to vote up to a particular bracket just to get it reviewed and hear whether it's ever going to make it to a backlog.

JPD would be a nicer way of approaching it. Would be a fun migration task!

[Nic Brough -Adaptavist-]

There's nothing I can even start to disagree with in that comment :-)

[David Meredith]

Thanks Nic.

Any advice / ideas on how this would reach Atlassian or gain enough interest to instigate some change?