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??
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:
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.
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
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