On Thu, 2006-08-10 at 18:06 +0100, Don Scorgie wrote: > Hi, > > On Thu, 2006-08-10 at 11:49 -0500, Shaun McCance wrote: > <snip> > > I think this went nicely, and I expect the release team > > will continue doing this. In light of this new process, > > I've been thinking over the last week of proposing a new > > rule. New modules proposals are not required to have > > documentation, but in the months between proposal and > > decision, maintainers must make a concerted effort to > > work with members of the GDP to make docs happen. > > > > Do bear in mind that, until feature freeze, any module, > > new or not, can change completely behind our backs. So > > we shouldn't expect to be able to produce complete and > > final documentation for new modules before the decision, > > because the decision happens at feature freeze. But we > > can get a big chunk of the work done, or at least know > > what we're getting ourselves into. > > Since new modules are quite a lot of work for documenting, perhaps an > earlier feature freeze should apply for them? Or some sort of "soft > freeze" where it is guaranteed that new features would only be added if > specifically requested by the release team (or to fix critical bugs). A > week or two before the real feature freeze, the expectant modules would > enter this soft freeze, in which time, documenting can start happening. > This at least would give our hard-working document writers a chance to > get at least a skeleton doc ready in time for feature freeze.
Another thing I've considered trying is having opt-in early freezes. Basically, if a maintainer thinks he is done with his module early (and this happens a lot), he can notify the documentation and translation teams that he's freezing his module early. The main reason I've never really put this on the table is that, without a status tracker, we'd completely lose track of who's opted into an early freeze. I think opt-in early freezes could significantly help in prioritizing our tasks, allowing us to get a lot of work finished earlier than normal. -- Shaun _______________________________________________ gnome-doc-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-doc-list
