[tei-council] open issues and planning

[Dan O'Donnell]

On Fri, 2007-19-01 at 16:17 +0000, Sebastian Rahtz wrote:
> Syd Bauman wrote:
> >
> Sorry, "probably quite a few" isn't good enough.
> What others, precisely? if they are recorded
> issues unresolved, let's list them, and solve them.
> Of course there are always more and more issues
> to find if we look hard enough, but the process must
> end soon if we are to meet our commitments.
> 
> "What commitments", someone will ask?
> 
> Well, if you (all) don't think we have a *commitment* to deliver
> TEI 5.0 completely ready for use by the TEI MM 2007,
> then we ain't singing off the same song sheet.
> > Not to mention that neither the editors nor the Council has announced
> > that they can be or are frozen.
> >   
> I didn't imply that. I said *I* regard them as frozen.
> 
> I propose a strawman timetable for us:
> 
>  1st February: accept no more feature requests for 5.0
>  1st March: all Sourceforge bug reports and feature requests from before 
> Feb 1 closed or definitely put off for 5.1
>  1st April: all implementation resulting from those SF things complete
>  1st May: (after council meeting) technical freeze of specs, only 
> serious bug fixes allowed after that
> 
> I have a feeling you are all going to get fed up with me saying this,
> but I feel very strongly that we cannot carry on in "ready when its ready"
> mode. We need at least minimal project management here, and that includes
> timetables and deadlines.

I agree. The board was quite serious about getting P5 done this year and
indeed had a "push money" line in the budget. The effort as currently
structured may not be sustainable much after this calendar year either,
as it is starting to take a toll on several major participants--or their
employers' patience. That's why I'd originally asked around to find out
when something is frozen.

Obviously it is a fine line: we also can't put out substandard work
either (not that that's ever been a TEI problem). And the Board and
several TEI partners seem quite interested in stability after P5 (i.e.
we should perhaps not move on to P6 right away if P6 means major
revisioning). Given the nature of what we are up, therefore, to perhaps
we should define "bug" to mean major conceptual issues with finished
work as well. What I mean by this is if somebody discovers a major flaw
in the underlying reasoning--something that would require us to move on
to P6.

I suspect from the above exchange that what we are really looking at is
agreeing on and formalising what we mean by frozen and what makes
something frozen: the things Syd mentions as not frozen fit Sebastian's
definition of frozen. Should process (or project management for the next
ten months--yikes!) be an agenda item after all? It certainly does seem
to me that we need to say "x is done--to propose changes, there needs to
be a serious issue involved."

-dan
> 
-- 
Daniel Paul O'Donnell, PhD
Chair, Text Encoding Initiative <http://www.tei-c.org/>
Director, Digital Medievalist Project <http://www.digitalmedievalist.org/>
Associate Professor and Chair of English
University of Lethbridge
Lethbridge AB T1K 3M4
Vox: +1 403 329 2378
Fax: +1 403 382-7191
Homepage: http://people.uleth.ca/~daniel.odonnell/