Thank ya’ll for your insights! I’ll try to address your comments one by one.
Yes, definitely. Delays in upgrades have always plagued the Open edX community. I think that by creating release-specific indices we can better keep track of which ones are not up-to-date. Because we will have a “maintainer” email address, we can get in touch with the authors individually and encourage them to upgrade.
I don’t necessarily agree. Yes, coconuts are deadly. But it’s important that you are clearly identified as the author and maintainer of a plugin; this is why the repo should be hosted in your GitHub account.
That being said, it’s important to prepare for a coconut scenario. But that’s what open source is for: anyone can fork your project if they decide to maintain it. And then in the contrib index we can switch to someone else’s fork if you’re coconutted for too long.
Yes, good point, I did not think of it. I’ll edit my TEP.
That’s a tough one 
I don’t have a definite answer, to be honest. But of course it’s a very important question.
I think that we should try to emulate the Ubuntu “universe” repository (which was the inspiration behind our “contrib” index): ContributeToUbuntu - Ubuntu Wiki
Basically, anyone can submit new packages to the MOTU provided that they are committed to their maintenance: Debian -- Work-Needing and Prospective Packages
We could probably adopt the same policy. We will have to pay close attention to the pace of upgrades for each plugin. Which leads us to your following question…
The official and contrib indices should be managed by Tutor maintainers – and not just myself. To be honest, I expect that these indices will need very little work. When a new release candidate is created, all plugins will be commented out from the index. And then we will re-introduce them one by one as maintainers upgrade them to the new release.
Yes, you’re right, and I definitely don’t want to be a bottleneck. I mean, you never know when an African swallow might fly over your house, right?
We now have Tutor maintainers for some (not all, unfortunately) of the official Tutor plugins. I did not grant commit rights to anyone else for the core repo, yet; the reason for that is that I’d rather wait until the Open edX code is extracted from the core (something that I mentioned here). I hope that we can reach that state soon, maybe before Olive.
In any case, the indices will have Tutor maintainers with commit rights, so at least these will not have to be forked when I’m coconutted.
Good point. I think that this feature can be part of the tutor plugins upgrade CLI – for instance with a -p/--partial option.
Yes, good point.
For these plugins we will have to add extra metadata to the index yaml file. But I don’t have the specs for these files, so I can’t give a more precise answer. I’m sure we’ll figure out something, though
yes
I think that we should make it very easy to enable the contrib index, but that it should not be enabled by default. Enabling it should be a conscious decision. If not, people will assume that contrib plugins are officially supported, which is not the case.
Absolutely. This is the current situation, but I’m sure that it can be improved by figuring out a better pacing for the release candidates. Hopefully, we should be able to work with plugin maintainers such that all plugins are ready to upgrade in time for the actual release. Of course, this can only happen if we communicate with plugin maintainers during the two months period between the release branching and the actual release date.
To @kmccormick’s point, I think that timely maintenance should be mandatory for plugins in the “contrib” index. What that “timely” means is of course the crux of the matter; my opinion is that it’s reasonable to expect that contrib plugins are either updated or forked before the release date, but I’m totally open to a discussion here.
For non-contrib, 3rd-party plugins/indices: maintainers should be free to upgrade whenever they want. And that’s the implicit contract of open source.