James makes three good suggestions and one not so good. 1) Mentoring is good and we already do it; the proposal is to enlarge the group of mentors to include non-currently-Council members. This is fine so long as the NCCM remains au fait with current Council practice. Less so if the latter has changed. You (presumably) don't want old farts saying "I dunno about this new fangled git nonsense". 2) Committers dont have to be on council (nor even formally council approved?). I think we already do this, don't we? 3) Advisory Group. This is the one I find not so good. It sounds partly like adding another layer of bureaucracy to the TEI organigramme, partly like reinventing the long gone "TEI-TECH" mailing list. If you want to consult the TEI community, consult TEI-L. End of (as you young people say). 4) Get the sorcerer's apprentice to write the handbook. Enthusiastically endorsed... and we already do it, don't we? On 04/08/15 11:46, James Cummings wrote:
Hi all,
I've been waiting to see where this discussion would go before commenting, and I think we are in danger of derailing some good ideas whilst accidentally combining some others.
Some of our worries concern: - the improving of getting new members (of whatever gender or technical background) up to speed not only with the basics but some of the more arcane mysteries of TEI Infrastructure and work - encouraging continued participation by those who were once TEI Council Members in all sorts of activities, but also technically competent people (whether ever on Council or not) as contributors to various technical aspects of Council activities - avoiding secret cadre of old farts (which I would abbreviate 'SCOFF', and leave it to you to figure out what the extra 'f' is for), or the sense that there is some division in the TEI of a high priesthood telling people what is good for them, whilst simultaneously recognising there are some arcane wizardly matters both technical and conceptual which do take a significant commitment to agree upon.
Having thought about it for awhile I am strongly against the idea of adding lots of additional people in any way to the tei-council list. I think that Council needs a place to discuss things as elected representatives without lots of chipping in from the public. If someone shouts down from the public gallery in the House of Commons, then they will be ejected. It is fine for them to sit and listen to politicians being morons, just as the TEI Community can read the tei-council mailing list. Indeed, I was one of those who argued that this list should be made public.[1] However, when they disagree with what we say, they don't have an equal voice -- but they can speak via representatives should they convince them of their point of view. However, I do agree the concerns above are real. I would propose the following suggestions which might help us overcome some of these concerns.
1) Mentors: Any new member (or indeed existing member who feels they wish it) can be provided one or more mentor(s) either on or off the Council who will agree to answer (to the best of their ability) questions put to them. If they ask me questions I will ask if I can answer them as blog posts in order to make the answer public and add to the disparate network of TEI documentation out there. Mentors must agree, of course, and be willing to do this. I am. This should be arranged separately from Council business by the chair of the council, but should be noted in the minutes.
2) Committers: Anyone previously elected to Council, or who desires it and is approved by Council (via apathetic assumption voting) can be added as a committer on any version control repository of any form that the Council is using for the development of software or guidelines if they so desire. If the person's interests only concern one aspect (e.g. Stylesheets) then we should give them rights to just that repository.
3) Advisory Group: The loss of experienced TEI old farts as they go off and get involved in other things is understandable and a waste of talent. We should set up an additional mailing list (which maybe is entirely open for anyone to join? But definitely open to read), and encourage ex-Council and others who wish to join to do so. This mailing list would be a TEI Advisors or some sort of advisory board, or whatnot. The benefit of this is that it gives Council (and presumably Board) a place to turn to in order to 'Ask the TEI Community' when they want distinct suggestions rather than approaching TEI-L as a whole. i.e. a subset of the TEI Community that is the most active and involved people from over the years. This should not just be those with Technical knowledge, but we should feel free to ask them quite technical questions. I would much prefer this than being co-opted back on to Council if I am not re-elected. (Unlike MartinH I've decided to stand again to help in what I feel will be a term where the Council transitions to new ways of working.)
4) Documentation: Get a commitment from some new members to actively produce documentation on some of the more obscure technical aspects of the TEI Infrastructure (as they learn them) for review and improvement by Council as working documents. I.e. Get them to write some of the policies and documentation for the systems we use as they learn about them, while asking Council for support and advice. This forces a very concrete way of learning some of the systems. We need to get to a point where if (over two generations) all quite technical people had left the Council that incoming ones could get back up to speed by reading the documentation we had left and experimenting with the infrastructure.
While these four suggestions won't necessarily solve all the concerns we might have, I do think if enacted they'd be an improvement.
-James
[1] http://lists.village.virginia.edu/pipermail/tei-council/2006/005757.html
On 04/08/15 08:36, Lou Burnard wrote:
On 03/08/15 21:15, Hugh Cayless wrote:
I Presumably then, you’re against being an invited expert again should you not be re-elected? :-)
Well, I am not against it in the sense of thinking it would be wrong to be asked; whether I would accept the request would depend on all sorts of other factors.
Personally, once off the Council list, I’m probably never going to look at it again unless someone specifically asks me to.
That's obviously a matter of personal choice. However, as Martin remarks, there are several existence proofs both for ex-Council members who never re-appear, and for several who do (e.g. Piotr, Laurent...)
I think we do way too much development work "in secret" and I’d like to find ways to broaden the community of TEI power users. That’s a different discussion though.
I am not sure what you mean by "in secret". The Council's list and its repositories are all open and public.
This is nothing we have to decide now, so we can wait to hear everyone’s opinion, and I agree that would be a very good thing.
I’ll just make two more points:
1) I am vehemently against asking anyone, e.g. Martin, to do work in support of Council’s mission without being formally recognized for it. I know he’ll do it anyway, because he’s an incredibly generous person, but I feel strongly that there ought to be a way that he can get credit for it and that he be able to say to his employer: "See, I’m doing this valuable work and it’s recognized by the TEI as such".
This situation comes with the territory though: we are an open source project. I rather suspect that letters from the TEI don't cut much ice with most employers when it comes to justifying use of time : if your boss has heard of and approves of the TEI, that's likely to count for a lot more (and fortunately this seems to be increasingly likely). But what do I know.
2) Would it not be more of a disaster to have a Council without the skills to implement their decisions and without any support or ways to acquire such skills?
Yes. One can imagine many disastrous scenarios. The point is though that a Council which is incapable of understanding the technical architecture of the TEI is not doing its job.