There was a discussion a bit over a year ago, under the General Discussion category, where @Kimberly asked for a General request for Feature request upvotes. In other ways: a public space where suggestions, feature requests, improvements, future development, etc. could be publicly discussed, between Duo users and the company team.
According to @Amy, the current company policy is the following:
Now, many Duo users are (not yet) Duo customers, even though they use Duo profusely on a daily basis, or have even developed integration with Duo on platforms for third parties (which, in turn, may be Duo customers, while the developers might not be). It’s obvious that in those cases there aren’t ‘Account Executives’ nor ‘Customer Success Managers’ to contact with ideas; all that remains is contacting the Support Team.
With due respect for the excellent professionals working at Support, I can imagine that they will be easily swamped over sorting through all the proposals and suggestions coming in from non-paying users — which means that they will have to juggle priorities and start addressing issues from paying customers instead. This would be most acceptable in all circumstances; also, when contacting Support, one assumes that there are serious issues regarding immediate technical support, and any Duo customer (and most non-paying users as well!) would not really wish Support to ‘spend too much time’ with issues not directly related to technical difficulties with the Duo ecosystem/framework.
While I understand that there is an internal documentation management system where all suggestions, feature requests, and so forth are duly archived on that platform, I tend to agree with @Kimberly when she says:
In other words: there are possibly a lot of similar issues from different users/customers, all of which might be addressed the same way; however, because these are filed separately, the following occurs:
- When contacting support (or any of the other possibilities) with what we think to be a new issue, we have no idea if that issue is already in the queue. This means that Support necessarily will have to go through lots of potential duplicates, and manually sort them to forward to the appropriate team that might pick some of those issues for implementation. This takes precious time away from actually being helping customers with technical issues.
- Similarly, even if we suspect that other people have similar issues, we might not report these, simply because, well, someone else surely must have reported it, right? This means that long-standing issues might go unreported just because ‘we all know that this must be being fixed’… when, in fact, we don’t.
- Development teams have a limited time to code, and the decision on what to do will depend on some manager’s ‘intuition’ about how important fixing issue X is. Because Duo is used across so many platforms, technologies, and market segments, such a decision is anything but ‘easy’; all this decision-making manager has to work with is a database with hundreds, thousands, tens of thousands of ‘unprocessed’ requests (in the sense that there will be certainly lots of duplicates, unfixable things, things already fixed or planned to do so, requests that are obsolete because the technology changed and made them irrelevant, and so forth), which, however, will have no easy ‘metric’ to aid such decision. The simplest metric (not necessarily the best, of course) is simply to see a list of features/requests, without duplicates, ordered by the number of ‘votes’ given by the actual users of the software. While certainly a lot of companies do not prioritise their internal development decisions that way, many do so — because the input of actual users weighs a lot in the perception that those users have about the software, and, conversely, fixing/adding a feature that is quite popular will, in turn, grow the users’ appreciation of the efforts made by the company to meet their needs.
- I understand that Duo is a security company, and, as such, many ‘requests’ or ‘features’ are not really appropriate to be discussed publicly, because such requests may include very sensitive data; as a result, I’m not proposing that confidential requests (and that includes eventual security breaches found, which should remain confidential until a new release is launched that addresses such issues) are made public, but, rather, that the vast majority of innocuous feature requests/suggestions/proposals are handled on a public forum — and having a Category in the Duo Community forums for that purpose would be excellent!
- Similarly, publicly-discussed feature requests/suggestions would allow a certain amount of discussion between users, which might result in several results even before the first line of code is written: proposals may get merged, or amended; users might contribute slight changes to existing proposals, which would go a long way to fix a larger range of issues; really unpopular suggestions — even though they ‘look good on paper’ and might even have been flagged for implementation! — will quickly become apparent during a discussion…
- There will be interactions between the development team (or at least a representative for them) and the user base. Typically, this could often ‘prune’ a feature request/suggestion by explaining how such a thing is technologically unfeasible, either in the short time, or perhaps even in the long time. This would allow a proposal — or a series of proposals — to be easily rejected, or archived, and stop wasting anyone’s time…
Here are two concrete examples from my very recent experience:
I’m currently beta-testing an application where there is an internal issue-submission tool allowing these kinds of discussions, as the launch date approaches and developers are swamped over with the code they still have to fix until the application can ‘go public’; over the past 2-3 months, more than 1400 issues have been raised, 800 of which have been either fixed or scheduled for future development — that way, beta-testers know they won’t need to insist on those 800 requests and focus their attention elsewhere; and developers will be happy to know that, when the launch date comes, practically all issues have been either fixed, or reviewed and postponed for future dates, thus allowing them to switch focus to what needs to be fixed or implemented now; all this, in turn, gets publicly documented as a ‘roadmap’, giving beta-testers an idea of when their ideas will be implemented. Note that this is neither the first, nor the last application I’ve been beta-testing which uses this approach; and I have to admit that, in the past two decades, I have already seen many different approaches to this model; I personally like some approaches more than others, but I’d say that even the ‘worst’ model is better than, well, nothing.
The other example shows how issues may go unreported for years, simply because we might assume that Duo is working on them, and will address them in a forthcoming issue… but we have no idea if it was reported, when it was reported, or if it’s scheduled for getting fixed… and this can drag over years!
A few years ago, the WordFence plugin for WordPress (a very popular security tool) incorporated 2FA on their free version (unlike Jetpack’s, which is paid). I have WordFence on automatic upgrade, and a few days after upgrading, I suddenly noticed that I couldn’t log in on those websites that were protected with the Duo WordPress Plugin. The website worked normally; users not protected with Duo’s 2FA could log in without any issue whatsoever; and the logs didn’t report any obvious anomaly. But I, as admin, couldn’t log in. Thus, I had to manually remove all plugins, log back in again, and install them all over again. When Duo was installed, I had to set up 2FA again — making sure that WordFence’s 2FA was disabled — and everything worked for that session. A few days later, however, the session cookie expired, and I got a blank page when attempting to log in again. Baffled, I repeated the procedure; and, this time, it was clear that either Duo or WordFence, on their own, would give no problems, but if both were active, it would be impossible to log in. There were no clues on either Duo’s or WordFence’s support areas. I could have raised the issue then, but… surely people would have noticed it before me, since, well, at least 20% of all the websites on the Internet run self-hosted WordPress installations and the WordFence plugin has been downloaded at least 3 million times, so, someone must have noticed this issue too and had already reported it’, I might not report it because it must be ‘obvious’ that it must have been reported… somewhere? But where? It’s not here in the Duo Community forums; it’s not on the WordPress support forum for the Duo WP plugin; neither on the open issues for the Duo WP plugin on GitHub; however, it is mentioned on the WordPress support forum for the WordFence plugin, an issue which was ‘closed’ 2 years and eight months ago… without a solution.
Eventually, as the poster on that WordFence support thread said, when choosing between Duo and WordFence, WordFence is far more important in terms of security, and since it also provides 2FA — even if just via OAuth TOTS — I just added it… to my Duo application. So I’m in the strange situation of having dozens and dozens of accounts on the Duo application which I use without the Duo protocol; while the few cases where I could use the Duo protocol I’m unable to do so because of the conflicts with WordFence!
I’m still waiting for a solution… because I refuse to believe that such an issue hasn’t been reported yet… but the truth is that, well, it has been a few years and I don’t even have a way to know if the issue was ever reported, or, if it was, when is a fix due to be released!
But I didn’t mean to use this Feedback category to surreptitiously file an issue — indeed, this category is meant to be for feedback about the Duo Community site. As such, I’m proposing that Duo adds a new category — let’s say ‘Feature requests and suggestions’ or something like that — which applies to feedback on the Duo software, and not the site itself. Such category would be employed by your support team to actually review and address all issues that aren’t confidential. There would be some ‘rules’ for adding new topics, such as a pre-defined template illustrating how to submit a feature request, and imposing the rule that ‘likes’ on the first article would count towards ranking it upwards in the list of priorities (always assuming that the support and/or development teams have reviewed such a feature request, considered it worth their time, and approved it for ‘general voting’), as opposed to having people replying in comments with a ‘+1’ or ‘me too!’ (which is always annoying). Evidently, the actual commitment by Duo to a specific feature would not be affected on how popular a specific feature request is; the popularity, measured in ‘likes’, would be only one of the metrics used by whoever makes the decisions at Duo about the development roadmap. A very useful metric, as said, but never the only one.
This would at least allow users — both paying and non-paying — to get an idea on which issues/suggestions/feature requests had been already proposed (the Discourse engine is not too bad at finding potential duplicates!) and, among those, which have a higher likelihood of being addressed in the future.
Thanks so much for your time reading this