[tei-council] Criteria for TEI Repository Inclusion
James.Cummings at oucs.ox.ac.uk
Tue Mar 2 19:44:40 EST 2010
Sebastian Rahtz wrote:
> On 2 Mar 2010, at 17:18, Julianne Nyhan wrote:
>> even if, as you say TEI-C did not create the e.g. customisation in question
>> it seems to me
>> that having a centralised access point for customisations could be
>> very convenient and useful.
> which is not quite the same thing as having ENRICH on SF next to TEI.
> Having a nice new catalogue on the TEI web pages would be very sensible
Should I point out that we have a place on the TEI wiki for putting
customisations? i.e. you can put an ODD in a wiki page if suitable, or
link to an external site. When we get the tei-enrich google code site
sorted out, I will be putting a link to that on the TEI wiki. However,
producing a list of them wasn't really my point, more when should TEI-C
conclude that something is central enough to the TEI to
store/develop/etc. as an exemplar or not. For example, the TEI Journal
will I assume have a slimed down TEI ODD for its schema... is this
something that the TEI-C SVN repository should contain? Or should it be
hosted separately? I'm undecided on all these questions.
>>> One thing to bear in mind is that the TEI SF SVN repository does not
>>> give fine-grained access. If you give access to personX as a developer
>>> on it, then they have the ability to add/change/edit the whole of the
>>> TEI Guidelines and any of the software above.
>> Yikes - in that case I guess it would be too risky. Is it possible to change
>> this at all?
> not that we know of.
When I last looked into it, the answer was no. You can give different
rights to different roles, but not assign them editing rights on one
particular branch or part of the repository in the way that SF has
> to be honest, the risk is small. everything is in a version control system,
> and I (at least) get an email telling me of every commit, so weirdnesses
> get picked up pretty quickly. If all else failed, I (or some other
> admin) would get back the state of last known saneness and restore over the top.
Sure, I mean, this is the point of having a version control repository
(well, one of them). But equally just from the point of view of a
separation of concerns, I could easily see that having, say, Roma, as a
separate SF project would make a lot of sense. But really that is
getting ahead of the very first issue of what should and should not be
in the TEI repository as a matter of policy.
More information about the tei-council