One of the aspects of our open source work that could use improvement is how best to deal with feature requests to our open source plugins. There have been various ideas proposed, however one reality they often come up against is resource allocation.
Context
Each open source plugin has a member who is responsible for it (they’re the one who will be auto-assigned the request when it’s made)
We have a policy of prioritising bugs over feature requests
Each member looks to spend about half the time they spend on paid work on “shared work” (which includes work on open source plugins)
Determining the “specification” for a new feature is half the battle (i.e. it takes time)
Most members are responsible for multiple open source assets
What happens currently
Currently, the way feature requests are handled is essentially dependent on who’s responsible for the plugin in question.
Is there anything wrong with this? I don’t think the maintainer has a responsibility to add new features - their main responsibility is making sure what we have works. Don’t think there’s a particular issue for features only being added if:
The maintainer feels like it
Someone else does the work and the maintainer/the org approves it.
It’s a paid job.
Of course they have the option of adding features as part of their shared work but I feel like that should almost always be optional.
I generally agree. I think we need to articulate this in a clear policy though. There may also be some inventive ideas we haven’t thought of before in this space.
An idea from a different perspective. What if we use or look at feature requests as a tool that can help the org grow?
There are various open source projects that had issues with getting contributions and so they would tag and sort their issues request in a way that people visiting could better find what to work on. This helped improve contribution and engagement.
This idea could be taken and remixed here, where feature requests are sorted into groups or buckets like pr-welcome or beginner-friendly or the likes and these could be used as tasks for new members looking to contribute. When we have a good number of these contribution tasks or ‘learning tasks’, they could make up a curriculum of some sort.
I say a curriculum because one of the fastest and most efficient methods of learning is learning by doing or the apprenticeship model. So by creating a curriculum from tasks we aren’t able to work on, we can help others learn by doing work on the tasks, while also improving contributions here.
I like it. We could perhaps also indicate the level of support we’d provide to people looking to attempt the PR. I’ve always found the pr-welcome tag a little passive in that respect. Maybe something like
beginner
moderate
advanced
Paired with something like
will-assist
your-on-your-own
The other question this raises is where we host this. We’re moving to managing all Discourse plugin work on https://plugins.discourse.pavilion.tech. That would be the natural place for this system to live.
The point of that server is that other plugin owners can also use it, i.e. a general plugin status, bug, feature and docs server.
I saw that instance the other day and felt it was really genius. This bit is most likely out of point here and so I put it as a separate reply, so we can move it to its own topic if needed.
Will there be a map or overview or some central hub or documentation that shows all the Pavilion instances?
I think I have joined about 3 or so, and it feels like they may be a lot to stay up to date in
A lot of times people find the plugins all the way useful (like 99%) but there always would be that one element or two that are missing or super important to them. I think it would make sense to have an option to allow such customers/users to pay for such features. Developing a new plugin altogether just to add one feature to an existing plugin doesn’t make a lot of sense to me that’s why I propose such a way of getting features added to a plugin.
The Process works somewhat like this:
User/Customer makes a feature request
The feature request is deemed out of the scope of plugin
Customer is willing to pay to add such a feature
An assesment is made based on the fact that it shouldn’t break the plugin or alter it in a significant way.
A quote is sent to client based on the work required to get the feature integrated.
The feature is added and a plugin update is released.
Some input might be required from the involved parties, Sometimes it is also desirable that such feature requests are crowd sourced by multiple interested parties.
This is the process you are describing yeah? I like how it details the start of the feature request flow. I smell a flow chart in the works to outline where a feature request starts and where it gets to.
The more I think about this the more I think feature requests should just always come with a price tag, even if it’s a small one. The issue at the moment is that people will make feature requests in the hope they will get included, however the most likely outcome is that we’ll either be too busy or the feature will be out of scope of what we have in mind for our own product vision of the plugin.
They indeed should (except when they’re already in our roadmap for a future update) the thing here being that sometimes people demand something that sounds reasonable but is technically a lot of work to implement.
One example would be to add an alternative payment method. Someone might say they don’t like stripe for some reason and would prefer some other gateway (e.g. paypal or crypto) such implementations sound reasonable but I know for a reason that are much harder in implementation.
That’s why I believe the maintainers should be compensated for such requests no matter how reasonable those sound.
That’s easily addressed by adding public roadmaps. Adding such roadmaps are generally a two-edged sword and causes anxiety among users when expected features don’t get added in time.
Interesting. Perhaps we could standardise this for plugins in the Plugin Manager System, i.e. have a sub-category in each plugin category for feature requests for the plugin.
)