[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