Server performance is just one point among several.
A project may be able to host a sprint during the year in general, but it may have
- periods during which scientists don't submit work,
- times when one experiment ends and a new one has yet to be launched,
- transitions to a new application version when new bugs may need to be ironed out,
- periods when they run into trouble with their hardware or with their hosting location, and they need a little time to get back to normal,
- staff on vacation or other business, so that nobody is around for quick intervention when unforeseen issues arise.
Some of these can be determined by outside observation. But most of it can be learned
only from communication. Some projects initiate such communication by themselves; they post announcements in their forum or as boinc notice. But in other projects you'd have to ask the admin (and will possibly be unable to reach them).
So, was there a hope that teams research these things and use their vote to weed out projects which cannot support the next scheduled sprint? — After typing all this, I no longer think that Sébastien had this in mind (it's just too far out); his intention must have been another one.
Personally, my opinion remains that per-sprint voting is bogus. It supports speculative bunkering (which some may like, others not). Secondly there is the (unintended or intended) effect that teams are, and shall feel, responsible for each sprint project selection, which somewhat shifts blame. So far I can't see any other effect [edit: let alone,
any actual improvement of the FB sprint modus].
Don't get me wrong: IMO teams should support Sébastien in this (that is: should be enabled to do so), such as being able to inform Sébastien about developments at projects which move them off or back on the list of sprint candidates. There is the FB forum, but it doesn't seem to be put to as good a use as it could be.
/ rant off. ;
-)
