Re: new apps without docs: policy request



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





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]