Hi there,
I took a moment and wrote down the background what I told to Ruben at the Conf. I should’ve done that earlier, but I have somewhere between 2 and 12 weeks of lag in my life at the moment.
It’s probably not covering 100% but it’s all feedback I got.
Addon packages handling and Review
Let’s pretend we get a new package or look at an existing one and want to go through a unified process for that. We want to avoid them being dead forever, and maybe we even don’t want them to die at all. Especially we don’t want them to die just because the Readme was hard to understand. So, what could we do??
-
ONE team should, with help from the author, test each plugin that is submitted for the marketplace.
A quick test of 1-3 hours.
The only criteria are:
-
that they’ve seen that it works and fully understand the feature set it adds
-
that the description is good enough for users to easily understand what it does and what value that provides
-
A plugin should be ranked based on:
-
Feedback: multiple users reporting that it works -> a star
-
Maintainer: does something with the project at least quarterly -> a star
-
Compatibility matrix: if you have compatibility info for multiple releases -> a star
-
Testing: if you help integrate tests for this -> a star
(vendor specific plugins will need to supply test results repeatedly)
Since OpenNebula has regular releases it’ll mean that projects can now go stale. Projects under a threshold of 2 stars would need to go to the sad valley.
- There should be a single exception though: As long as someone reports that it’s WORKING + WORKING on a version not more than 2 years of age, it will not go to the sad valley, even if it IS unmaintained.
To easily achieve this, each ecosystem addon should have a standard document.
Either linked or directly contained in the Readme.md
I think the readme is better and simply put, you can only get in the marketplace if you have this piece of the text.
Users can then add PR’s to indicate i.e. that they use it.
We need to decide if it’s enough if the author vouches that it’s still working. I tend to think that this is fine as long as he also supports it.
Stale PRs of more than a year without discussion -> sad valley
Generally it’s a hard topic since as long as the plugin works people will probably not even once a year check the status.
A good example:
Please look at this ansible module:
http://docs.ansible.com/ansible/win_chocolatey_module.html
It has a status, and it has a supporter field.
This actually means one can’t just take the fame without the blame.
If you want to add a module, you need someone to support it.
Support channels for plugin authors
I would highly suggest ‘OpenNebula the company’ has a standard “we support it for you” offering that vendors can use for their plugin.
(i.e. custom plugins for a storage array, the vendor might deal with a lot of software, and rather pay someone to keep their code working & well-integrated than clock in to your release cycle)
Whereas for no-money community contributors each new release might be exciting so that they’ll probably like to work on it.
A smart move would be to dedicate 2 hours / year from your dev time to supporting them on request. So, 2 hours per addon in the ecosys,
It should pay back since they’ll be release quicker and won’t go stale if the author hits a wall.
I don’t mean this should also include all contributors on a plugin, but the ones who start it with a lot of energy and might not be able to resolve an issue 2 years later. So the current, finally responsible maintainer.
Any project you already flagged to be moved out to the sad valley should just go there.
If someone adds a “I use this and it works” commit that would be enough to bring it back.
If you like the idea of a standardized header in each project I think we should add that also to the ones that are moved now.
tl;dr
In summary, my suggestion is
- to rank plugins (1-5)
- to add a feedback/metadata area for each addon SUPER MEGA MOST IMPORTANT THING
- to test each plugin with the author when it arrives
- to budget a very minimal amount of time to support plugin authors
- to put high positive value on the feedback if something works
- to put high negative value on the compatibility matrix and bad care of PRs
- to offer supporting the commercial authors of plugins
####Disclaimers:
Of course, these are just suggestions. I just wanted to write them down since I care. Pick whatever suits you, or none.
I mentioned Ansible. I use it. And I use other tools which I consider better at the same task. Just so we got that one straight