We’re extremely fortunate at Figshare to have millions of users from a variety of backgrounds engaging with our platform. That might be as simple as downloading a PDF from a preprint server or uploading your code all the way up to the administrators of repositories from some of the biggest technical universities in the world and even looking at research data outputs at a national level. With all of these users, we get lots of feedback and with this blog post we want to take a look at how we handle it and how it affects the development of the platform.
We receive so much feedback! We love how much we get as it shows an engaged community all imagining and pushing for the same goal: How can research be distributed and managed better?
It’s a real thrill to have so many touchpoints with our community, and here’s a non-exhaustive list of some of the ways we get feedback:
Adding all this alongside internal feature requests, innovation ideas and improvements can create quite the backlog, and that’s where organisation comes in.
Depending on the type of request that comes in, it will either:
The Figshare feature request forums are a great place for community discussion and upvoting. If we receive a request via an alternative method and add it to the feature request forums, it’s because it’s something we’re not sure should go straight to the backlog or into development and want to assess community sentiment before proceeding. The upvote mechanism on the feature request boards is also a great method of quickly assessing appetite for a particular request.
The current development backlog and development schedule are outlined in our Product Development hub which has links to our Public Roadmap, along with some other great resources.
When we look at any given feature request (be that internal or external), we have a framework by which we analyse the prioritisation level for that request. We call these our Development Pillars, and we find them a helpful tool for objective analysis of often wildly-disparate requests.
A couple of Pillars take priority over the others:
Security or technical risk
If we did not action this request, would we be exposing our clients and users to any undue risk from a security or technical perspective? These requests will always take absolute priority over all other requests.
Policy, regulatory and legal
Although generally less time sensitive than the above, policy, regulatory and legal risks again will always take priority. For recent examples of this, see GDPR compliance and recent accessibility changes that came into force for Public Sector organisations in the U.K. Ensuring compliance to the deadline is something we are very proud of achieving.
The remaining Pillars’ priority will change in weighting dependent on the feature, but the ideal feature request will address every one of these Pillars to an extent.
Usage
Does the request assist in getting our users to upload and interact more with the platform? This is quite a broad category and it could be anything from improving personal statistics to automated GitHub integrations to mobile improvements. Anything which makes it an easier, more encompassing and enjoyable experience.
Quality-of-life improvements
We have many paying clients at Figshare and it’s vital that we ensure their voice is heard. Anything that can make their life easier, from improved Admin tools to preservation system integrations to specialised reporting are all taken into account when building out the roadmap.
Extending value to existing clients
One of the great things about Figshare is how many different ways our users and clients use the platform. Sometimes, a feature request can unlock a whole new use case for an institution. For example, Restricted Publishing enabled our clients to use Figshare for teaching material dissemination and theses management! If we can do this and provide more value for our existing clients at no cost then we will value this request very highly.
Innovation
Whilst it’s great to ensure all the potholes in the road you are walking on are filled in, sometimes it’s nice to gaze at the stars! If the request is helping push things forward in the open science or research technology space, tackling problems in a way that might not have been tried before, then this will really help weight the prioritisation.
Sustainability
Sustainability is vital in academic infrastructure. As Figshare approaches its 10th year, our commitment to sustainability has been shown to be prudent in establishing the secure foundations that we thrive off today. This commitment doesn’t only look backwards, as more clients means a bigger team, a better product and a more secure future. As such, we need to judge if the feature can help with the needs of the marketplace looking for solutions now.
Community standards and practices
As a rule, we will always try to integrate and support accepted community standards and practices when implementing new functionality. This has influence on prioritisation if we know, for example, that there will be a major community standard change in the short to medium term that will directly impact a feature.
Technical feasibility
Again, this is a broad category that encompasses a lot of areas. The two key aspects are as follows:
Product direction and ethos
Whilst some requests are ostensibly good, they may not fit in with the direction that we wish to take the figshare platform. This is not to say that our direction is immutable, community demand has influenced that significantly in the past, but our overall vision of open research has never changed since the beginning and requests that are at odds with that vision are unlikely to be accepted.
The rejection rate for requests is low, around 10%. The most common response you will receive from the Product Team is one of “Deferred”. This will generally be contextualised with a response, but typically means that whilst we agree that it is a good request, it doesn’t meet enough of the Pillars above to be moved to Backlog or even Development.
Once a request has made it to the Development Backlog, we may take a number of additional steps to validate our approach in how we should handle it. This is generally if the feature is very large, very important or operates with a number of unknown parameters.
Request for comment docs
Open to all, we outline an initial proposal in full and then receive community feedback and discussion. Proposals are iterated until the final specs for development.
One to one/group-based user testing
Thanks to our engaged community, we have access to many different types of Figshare users. From early sketches up to clickable prototypes, access to these users helps us gain critical feedback in our decision making process.
Focused working groups
Where appropriate, smaller working groups around focused features are convened. This is generally only applicable to optional feature sets.
Formed at the beginning of 2021, the Accelerated Feature Requests & Bespoke Configurations Team was formed in direct response to client demand. This team enables Figshare clients to push the delivery date of specific feature requests to an earlier release at a cost. How much earlier will be specific to the nature of the request, affected areas, complexity and current number of accelerated development requests being worked on. The range is typically from 1 to 9 months from the signing of a Statement of Work to a feature being released to production. Almost all work developed in this way is available to the Figshare community at no additional cost.
The Product Development hub has links to:
There are also product webinars with Q&As.
If you’d like to talk more about Figshare’s features, releases, and what’s in store for the platform, please get in touch at info@figshare.com.
For further information, contact your technical account manager or chris@figshare.com
Jan 25, 2021 18:16
This is a reposted article from our blog, the original article can be found at:
https://figshare.com/blog/Community-driven_development_at_Figshare/611