[tei-council] Criteria for TEI Repository Inclusion
julianne.nyhan at gmail.com
Tue Mar 2 12:18:57 EST 2010
>when a new piece of software or important TEI
>Customisation is being created, when should it be considered part of the
>TEI SF repository and when should it be hosted elsewhere?
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.
>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?
On Tue, Mar 2, 2010 at 5:58 PM, James Cummings <James.Cummings at oucs.ox.ac.uk
> Hi there,
> We were having a discussion recently about a TEI Customisation that we
> created for the ENRICH project and its future maintenance. Although I
> believe we're leaning in favour of setting up a separate Sourceforge or
> Google Code repository for it and managing it separately from the TEI SF
> repository, somehow 'donating' it to the TEI-C was suggested at one
> point. While I frankly think it is better for such things to be managed
> separately form the TEI, it made me realise that we don't seem to have a
> set policy on when something (an ODD, a piece of software, etc.) gets
> included in the TEI SF repository and when it doesn't.
> Currently we have directories for the following:
> And of course a number of ODD files in P5/Exemplars/ which are the
> templates provided in Roma.
> The question is when a new piece of software or important TEI
> Customisation is being created, when should it be considered part of the
> TEI SF repository and when should it be hosted elsewhere?
> 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. Currently I'm just trying
> to have us think about when something should be part of this repository
> or not, and under what circumstances we might 'adopt' things that the
> TEI-C itself did not create. However, I could see good arguments for
> making things like the Stylesheets, Roma, Vesta, TEIOO, etc. separate SF
> or other projects at some point in the future.
> Any thoughts?
> tei-council mailing list
> tei-council at lists.village.Virginia.EDU
Dr Julianne Nyhan,
Kompetenzzentrum für elektronische Erschließungs- und Publikationsverfahren
in den Geisteswissenschaften
Fachbereich II / Germanistik
+ 49 (0)651 201-3358
More information about the tei-council