We are really close to having a documentation process that can actually keep up, and to being able to freeze our documentation for translations. We just need to make sure we're documenting something stable.
In the past, we've had three points in the schedule to help: the UI change announcement period, the feature freeze, and the UI freeze. Feature freeze is gone from the 3.3 schedule, which confused me a bit, but I want to propose something different anyway. The main problem is developer awareness. Developers don't know exactly what constitutes a change that the documentation team cares about. And it's sometimes hard to keep of which freezes and announcement periods are in effect. Two-fold proposal: 1) Drop the UI change announcement period. It was a nice idea at the time, but it just doesn't help me much. It's not worth the developer mental overhead. 2) Merge the old feature freeze and the UI freeze into one big freeze and call it something that suggests you're not supposed to make changes. I've been calling it THE freeze. I'm not good at naming things. Beta freeze? Software freeze? I had wanted to do the freeze with the 3.3.5 release, which is where we would do feature freeze. But I fear it doesn't make sense to do it before the Brno hackfest. When we're in the freeze, you don't make user-visible changes anymore. No new supported formats or protocols or backends. No new UI. No changes to how a user interacts with the UI. You can fix crashes and address performance problems. In case you're worried this will stifle development, remember that you have 21 weeks to go wild. That's 80% of the entire cycle. And all you have to do to make a change is send an email (or if we go with Bastien's proposal, file a bug). In eight years, I only remember blocking one change proposal. -- Shaun _______________________________________________ desktop-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/desktop-devel-list
