Proposed Freeze Change

[Shaun McCance <shaunm gnome org>]

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