[tei-council] Criteria for TEI Repository Inclusion

James Cummings James.Cummings at oucs.ox.ac.uk
Wed Mar 3 07:21:52 EST 2010


Sebastian Rahtz wrote:
> I would question your use of "well used".  Yes, there is a representation of code
> there, which one has to painfully copy and paste (from memory), but
> we have done no analysis of any kind on whether it is effective,
> appreciated, or has had any impact. It might well be/have had, but
> we don't know.  

That's probably fair.

> But my hatred of wikis makes me digress, sorry :-}

They aren't ideal for many things, even what they were designed 
for, but some people like them.

> agreed. and whether its "adopt yes/no"
> or "adopt entirely /  manage development of / just provide space for"

Yes, the latter is really the question. We do the first two in SF 
SVN and (for what it's worth) the last of these on the TEI wiki.

> do you think, being serious now, that the barriers to SF and Google Code
> are too high for the casual user? or can we just set up a "TEI contrib" project?
> I'd say that an unmanaged project is doomed to failure, and that
> we (TEI Council) cannot justify time spent on management from our
> very limited budget

The problem is, as you say, ongoing management.  Even if we just 
had a contrib/ directory in subversion, when groupA had a new 
version of their nifty 'script to tell you what's changed in the 
TEI since you first made your ODD', then someone would have to 
get the released file and put it into that directory etc.  This 
also, of course, loses the benefit of version control. How do 
other projects manage this sort of contribution? Some software I 
use has plugins and such that are distributed along with the 
software and these are available from the equivalent of a 
contrib/ directory in the SF SVN repository... I wonder if they 
just give access to loads of people or have a developer whose job 
it is to keep those up to date.  As a thought experiment, what 
are the arguments against having a contrib/ dir and giving one 
developer from each project in there developer access on the 
subversion repository?

Extra time spent reverting their changes to the main TEI source? 
Some form of legitimisation of their dodgy code as reflecting
the TEI?

Just thinking out loud, apologies.

-James


More information about the tei-council mailing list