= phenomenon =
Figure out creation of F20+ schedules based on F19 experience
= background analysis =
For F19 we have used different approach to schedule the release - to actually plan the release and set the schedule based on the scope of submitted features and the amount of work needed to finish planned changes. It allowed us to merge mass rebuilds to one and set branch date based on this, to give more time for features that needed something done before a milestone (cloud images), Anaconda etc. For this part - it worked very well but on the other hand - we completely forget other teams in Fedora except developers and with very unclear schedule (we have just set the minimal goal for release, still better than nothing for guidance) - they could not plan their work properly and were complaining. It was also very hard to communicate it and even with BIG EXCLAMATION marks, community still took it as a final date.
The new way of creating schedules also leads to slight departure of six months releases (we still try but what if some feature we would really like to have would lead to 8 months - and it happened with New UI for Anaconda etc.). So I think this is also a task for Board and broader community, to agree on.
= implementation recommendation =
Well, it's now for discussion - but I think as these "guidance target release date" was not understood correctly and seems we really need more solid overview of release timeframe, I'd propose going slightly back. The idea would be - to select final Feature Submission Deadline as we did for F19, do a better job in communication (I'll try, but looking on submissions and only one after the deadline, I think it was quite well communicated and understood, except one complain) but for the rest of schedule, we should provide more details. As for F19, set target goal, but more as a draft/tentative schedule, not saying it's not schedule at all ;-) and give other teams better overview with reminder, it can move forward or other changes could happen. It's planning/scheduling, so there's always such risk. But this could give them more confidence.
As I think we covered most of the ticket in https://fedorahosted.org/fesco/ticket/1095 (Fedora 20 Schedule Draft), I'm going to close this ticket. I'll take care of the Board part myself.
to comment on this ticket.