I think I agree with most of this (I usually do agree with MH!) But am skeptical about a 'contributors' list'; I see no reason techie discussions should not take place on TEI-L, which is hardly prone to excessive traffic, where they would raise the general tone and educate, by osmosis. pfs On Thu, Dec 3, 2015, at 17:00, Martin Holmes wrote:

Hi Hugh,

Thanks for getting all this going. I'm actually looking forward to being more active next year than I have been recently, because I'll no longer be the managing editor of the Journal, so I hope to be a good test case for staying involved.

I don't think contributors should attend telcos or FtFs except in rare cases where they might be brought in for part of a meeting to talk about a specific issue. As we discovered today, there are technical limitations on the number of participants in a telco, and in any case, when too many people are present, some folks inevitably become less willing or able to contribute (I'm thinking especially about people whose first language is not English, and might get lost when discussions get too voluble or too many people are speaking.)

I'm in two minds about whether contributors should remain on the mailing list. If it gets too large, discussions will become incoherent and inconclusive. There's the obvious issue of who decides who should be on it and who shouldn't. And the fact that this is the Council mailing list means that it should really only host Council deliberations.

There are some alternatives that might be workable, though. We could have a Contributors mailing list, to which one designated member of Council would subscribe for the purposes of acting as a bridge to Council (others might subscribe too if they're interested). This would have to be clearly distinguished in intent from the regular TEI-L; it would be for expert-level discussions, and perhaps restricted initially only to people who have been on Council, and who can therefore be expected to understand to some degree how the repos and build processes work. Alternatively, we might consider it also as a pathway onto Council; people might join that list and learn how to contribute and how things work, and then use their demonstrated willingness to contribute as a factor in their election run for Council. You could have a pathway such as:

- Read the list - Ask to join it and be added - Read documentation and learn about git etc. - Be assigned some straightforward tickets - Carry them out - Stand for Council in the next election

That would ease the transition onto Council as well as off. People who never got to the ticket stage, or who never completed tickets assigned to them, could be removed from the list after a specific period, presumably after learning that it's not for them.

There are other aspects of cycling off Council that need to be considered. I have credentials to access the tei-c.org server. Should I lose those? Ideally there should be a periodic review (perhaps once a year) of everyone holding such credentials, and the Council would decide whether they ought to continue to have them.

Cheers, Martin

On 15-12-03 01:37 PM, Hugh Cayless wrote:

...

Dear All,

Thanks for the productive meeting earlier today. I’d said I wanted to broach the topic of keeping Contributors engaged over email, partly because it’s been a little contentious in the past and partly because I think it’s something that deserves more deliberation than we can give it in a single meeting. I’ll start by setting out how (as I understand it) things work now and then paint a picture of things as I’d like them to be. I mean the latter as something for you all to react to, so don’t hesitate to do so. I’d particularly like reactions from those of you who are new to Council. This is really going to be an ongoing conversation, I believe, and not something we can just fix. Martin has volunteered to be a champion for Contributors and I’m hoping that he and any other outgoing members who want to remain active participants will be vocal about what works and what doesn’t work for them. Council is a highly effective group that does a lot of good work, so we need to find a balance that doesn’t mess with our effectiveness and cohesiveness.

The status quo:

Engagement with TEI work happens via the TEI and Stylesheets repos on GitHub. Each of these has issue trackers, and there are two teams that have access to make changes to TEI, the Technical Council and "TEI Contributors". Incidentally, if the new folks will send me their github ids, I’ll add you to the Council team. The Tech Council team is for current Council members and the Contributors team is for a) former Council members who wish to remain active and b) anyone else we decide should have the ability to push directly to the TEI repo. This being GitHub, we can also take pull requests from people on neither team. Discussion of TEI stuff happens on this mailing list, on the issue trackers, in our monthly telecons, and in our Face to Face meeting. Only current Council members are on the mailing list, and people are removed as they cycle off Council. Only Council members attend the telecons and the F2F meetings, though occasionally "outside experts" are invited. Council tends to operate on consensus, though from time to time contentious issues are put to a vote.

My ideal world:

Contributors would be able to be as involved as they want to be in ongoing TEI development. That might include staying on or joining the mailing list, attending telecons, and even F2F meetings (though the TEI wouldn’t be able to pay for them unless they were formally invited of course). The main difference between Council Members and Contributors would be that the former have a vote when things come to a vote and would in general have more responsibility for development and maintenance.

I feel that we don’t do enough to foster an active community of people who are TEI experts, and I think part of that is Council being a bit mysterious and exclusionary. It’s hard to get onto Council, especially if you’re not already part of a community of TEI users (so that you have name recognition in the elections) and people who leave have tended to just drift away (often leaving unfinished business).

As I mentioned above, we’ve had a version of this discussion before, and I think mine was a minority view then, but I wanted to raise it again now to get the reactions of our incoming members and the perspectives of our outgoing members. What should we do? As you might have guessed, I have strong opinions, so I’m going to shut up for a while in the hope that a productive discussion develops without me driving it :-).

-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived -- Paul Schaffner Digital Library Production Service PFSchaffner@umich.edu | http://www.umich.edu/~pfs/

I don't think anyone's arguing against widening access to the Council's deliberations. However, I do think that an important, possibly the most important,. thing the Council does (eventually) is MAKE DECISIONS. In that sense it is not just a general discussion forum: it is also an executive. Which is why I would vote against blurring the distinction between the Council and the body of people supervising, criticising, or even contributing to those decisions. If having lots of people in a telco makes it inefficient, so does having lots of people contributing to a mailing list (possibly even more so, since it's all too easy for email discussion to go off on a tangent). So while I am all in favour of making it as easy as possible for Council discussion to be read by as many people as possible, I think that contributions to it should come via our usual open route, i.e. TEI-L. As Paul notes (and I agree) there is no need to set up a separate "techie only" discussion list (and when we did it was a resounding failure, fwiw) As to the role of ancient monuments like myself: when I come off Council, I fully intend to continue to scrutinize Council discussions and if so moved comment on them on TEI-L. I also expect to be continuing to tinker with ideas for improving the TEI Guidelines, which I will feed into the Council's deliberations. But I do not expect or desire to be given any special title or status as a result. On 04/12/15 10:02, Magdalena Turska wrote:

Hi,

As I see it, council list is publicly archived anyway, I don't expect allowing other people to join should raise any issues - anyone who's interested in reading can do it anyway, but list subscription would make it a lot easier to follow the discussion. The only 'danger' would be sudden high volume of traffic from outside of Council, but let's be realistic how likely is that. So I'd be all for opening the council list for anyone. Keeping separate contributors list is a great idea if you want to have one more dead list with 0 traffic on your mailserver :)

For telcos I do support the view that too much people makes them very inefficient, so unless there's a specific reason to invite someone, no point in doing that. For f2f though, especially if they happen to coincide with a conference some of you did say already that the open Council session in Lyon was a good experiment, so why not repeat it (with some disclaimer how many ppl max council can accommodate?).

As for pushing privileges or organization membership, I expect that once one someone gets it, there's no real need to revoke them just because someone's term on the Council has come to an end? To avoid misunderstanding we might skip the 'Council' tag altogether. As a side not for the repos, is there a policy already like 'let's only work via pull requests' or 'don't ever merge your own changes', to keep some level of peer review there?

All in all, the goal from my perspective is to keep as many ppl involved in active development and infrastructure maintenance as possible. Which is obviously hard as we all are busy with our dayjobs. So we shouldn't impose formal barriers for those rare specimens who might fancy devoting their private time to TEI.

Best,

Magdalena

On 4 December 2015 at 02:06, Paul Schaffner wrote:

...

I think I agree with most of this (I usually do agree with MH!) But am skeptical about a 'contributors' list'; I see no reason techie discussions should not take place on TEI-L, which is hardly prone to excessive traffic, where they would raise the general tone and educate, by osmosis.

pfs

On Thu, Dec 3, 2015, at 17:00, Martin Holmes wrote:

...

Hi Hugh,

Thanks for getting all this going. I'm actually looking forward to being more active next year than I have been recently, because I'll no longer be the managing editor of the Journal, so I hope to be a good test case for staying involved.

I don't think contributors should attend telcos or FtFs except in rare cases where they might be brought in for part of a meeting to talk about a specific issue. As we discovered today, there are technical limitations on the number of participants in a telco, and in any case, when too many people are present, some folks inevitably become less willing or able to contribute (I'm thinking especially about people whose first language is not English, and might get lost when discussions get too voluble or too many people are speaking.)

I'm in two minds about whether contributors should remain on the mailing list. If it gets too large, discussions will become incoherent and inconclusive. There's the obvious issue of who decides who should be on it and who shouldn't. And the fact that this is the Council mailing list means that it should really only host Council deliberations.

There are some alternatives that might be workable, though. We could have a Contributors mailing list, to which one designated member of Council would subscribe for the purposes of acting as a bridge to Council (others might subscribe too if they're interested). This would have to be clearly distinguished in intent from the regular TEI-L; it would be for expert-level discussions, and perhaps restricted initially only to people who have been on Council, and who can therefore be expected to understand to some degree how the repos and build processes work. Alternatively, we might consider it also as a pathway onto Council; people might join that list and learn how to contribute and how things work, and then use their demonstrated willingness to contribute as a factor in their election run for Council. You could have a pathway such as:

- Read the list - Ask to join it and be added - Read documentation and learn about git etc. - Be assigned some straightforward tickets - Carry them out - Stand for Council in the next election

That would ease the transition onto Council as well as off. People who never got to the ticket stage, or who never completed tickets assigned to them, could be removed from the list after a specific period, presumably after learning that it's not for them.

There are other aspects of cycling off Council that need to be considered. I have credentials to access the tei-c.org server. Should I lose those? Ideally there should be a periodic review (perhaps once a year) of everyone holding such credentials, and the Council would decide whether they ought to continue to have them.

Cheers, Martin

On 15-12-03 01:37 PM, Hugh Cayless wrote:

...

Dear All,

Thanks for the productive meeting earlier today. I’d said I wanted to broach the topic of keeping Contributors engaged over email, partly because it’s been a little contentious in the past and partly because I think it’s something that deserves more deliberation than we can give it in a single meeting. I’ll start by setting out how (as I understand it) things work now and then paint a picture of things as I’d like them to be. I mean the latter as something for you all to react to, so don’t hesitate to do so. I’d particularly like reactions from those of you who are new to Council. This is really going to be an ongoing conversation, I believe, and not something we can just fix. Martin has volunteered to be a champion for Contributors and I’m hoping that he and any other outgoing members who want to remain active participants will be vocal about what works and what doesn’t work for them. Council is a highly effective group that does a lot of good work, so we need to find a balance that doesn’t mess with our effectiveness and cohesiveness.

The status quo:

Engagement with TEI work happens via the TEI and Stylesheets repos on GitHub. Each of these has issue trackers, and there are two teams that have access to make changes to TEI, the Technical Council and "TEI Contributors". Incidentally, if the new folks will send me their github ids, I’ll add you to the Council team. The Tech Council team is for current Council members and the Contributors team is for a) former Council members who wish to remain active and b) anyone else we decide should have the ability to push directly to the TEI repo. This being GitHub, we can also take pull requests from people on neither team. Discussion of TEI stuff happens on this mailing list, on the issue trackers, in our monthly telecons, and in our Face to Face meeting. Only current Council members are on the mailing list, and people are removed as they cycle off Council. Only Council members attend the telecons and the F2F meetings, though occasionally "outside experts" are invited. Council tends to operate on consensus, though from time to time contentious issues are put to a vote.

My ideal world:

Contributors would be able to be as involved as they want to be in ongoing TEI development. That might include staying on or joining the mailing list, attending telecons, and even F2F meetings (though the TEI wouldn’t be able to pay for them unless they were formally invited of course). The main difference between Council Members and Contributors would be that the former have a vote when things come to a vote and would in general have more responsibility for development and maintenance.

I feel that we don’t do enough to foster an active community of people who are TEI experts, and I think part of that is Council being a bit mysterious and exclusionary. It’s hard to get onto Council, especially if you’re not already part of a community of TEI users (so that you have name recognition in the elections) and people who leave have tended to just drift away (often leaving unfinished business).

As I mentioned above, we’ve had a version of this discussion before, and I think mine was a minority view then, but I wanted to raise it again now to get the reactions of our incoming members and the perspectives of our outgoing members. What should we do? As you might have guessed, I have strong opinions, so I’m going to shut up for a while in the hope that a productive discussion develops without me driving it :-).

-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived -- Paul Schaffner Digital Library Production Service PFSchaffner@umich.edu | http://www.umich.edu/~pfs/

-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

Dear Hugh and Council-in-Transition, I'm of a couple of minds here: First, I thought one of the roles of Council members was to monitor and respond to questions on the TEI-L list, and to field that list for new ticket items. Since that seems to me our most active and visible community role, it seems important to recruit for Council and stay connected to past Council members there. But what about the actual assigning of tickets and doing specialized work that Council doesn't discuss much with the wider community--like updating a Jenkins box (for an example)? I didn't know much at all about these until I attended a first Council meeting in Lyon, and I could see how the interests of supporting infrastructure wouldn't easily be introduced on TEI-L. And they are of immediate interest to the Technical Council. Maybe we should make this a matter of Decision (following the spirit of Lou's response) for the outgoing members and the Council together: Ongoing Council members know the issues and range of open tickets best and have to orient new members to them, and it seems to me (just getting started here) that there's Much for us new people to do and learn. It looks to me as if Council itself as a group easily identifies outgoing members who want to stay active based on their expertise and interests, and in that case, Council can decide to introduce these people to Council as active Contributors who will stay around on GitHub and remain on the Council mailing list to advise and update. How long will a Contributor remain active? Council itself will be able to monitor that, and perhaps as an order of business each year can decide to check in with Contributors who haven't been heard from in a while and drop from the Council list when they are quiet. As I think about this, I would really appreciate the benefit of consulting with anyone knowledgeable about the range of technical work that I've not seen discussed on the TEI-L. That's where I've learned a lot too, but that list just doesn't cover a lot of what Council actually does. I think I agree with what others are saying here, that Contributors can't easily be part of meetings, but might be invited to present there. But Contributors I think should continue on the Council list, AND Council itself ought to be as active as possible to educate the TEI-list. Introducing a third list might introduce confusion and inefficiency. Whether potential new recruits for Council could be recognized and given Contributor roles (like what Martin describes) seems potentially more vexed--and not quite the same thing since these people would not be knowledgeable of Council processes and decision-making as outgoing Councillors are. I like the idea of mentoring toward Council election (and that would be a powerful thing to be able to state on a candidate nomination statement)--but I think that too should be a matter of decision by Council (so we all know everyone involved with tickets) and such Mentees or Understudies will definitely want to be part of the Council mailing list. I may not understand this well yet, but is there anything especially confidential in Council list content? If not, we might well just want it to be open to anyone to subscribe in the interests of transparency--and periodically invite TEI-L members to join as they wish. Those who join are likely the kinds of people who'd want to run for Council. I think the actual work of the tickets is something we need to make sure is being done by people knowledgeable and in the loop on Council decisions. So in a Council meeting, we want to review together Who's doing What, and make sure we're all clear and in agreement on what work is best handled by Contributors and fine to delegate to Mentees. On GitHub, I'm ebeshero , and happy to be on the Council with you all! Best, Elisa Sent from my iPad

On Dec 4, 2015, at 6:56 AM, James Cummings wrote:

Hi all,

I can see benefits and drawbacks on both sides, but generally agree with Lou's point of view below.

I think only Council (and ppl like webmaster) should be on the council list since it is an open but elected body. I like Magdalena's idea of not necessarily distinguishing between Council and other Trusted Developers on github, but if both have the same github privileges, then it doesn't really bother me if there such a distinction. I am actively against the idea of a TEI-tech mailing list (it has been suggested before and as Lou notes wasn't successful). I learned my TEI mostly from 1999-2003 by eavesdropping on the TEI-L mailing list and asking people lots of stupid questions. I learned it even more when I started trying to answer questions. I'm sure I still have a lot more to learn. The technical conversations there are easily ignored by users who are not interested and raise the technical literacy of the community for those who do eavesdrop. (And by technical literacy here I mean specifically of the TEI infrastructure.) Indeed, I'd encourage Council to have _more_ technical discussions on TEI-L when we're discussing a particular ticket/issue so as to involve the wider community more regularly. I.e. the council list should be for council business (which includes making the decisions) but general discussion of issues that are potentially of interest to a wider audience we could include more people. I also agree that Lou shouldn't be given any special title or status when he departs council. ;-) He knows he already has that in our hearts.

-James

...

On 04/12/15 10:16, Lou Burnard wrote: I don't think anyone's arguing against widening access to the Council's deliberations. However, I do think that an important, possibly the most important,. thing the Council does (eventually) is MAKE DECISIONS. In that sense it is not just a general discussion forum: it is also an executive. Which is why I would vote against blurring the distinction between the Council and the body of people supervising, criticising, or even contributing to those decisions. If having lots of people in a telco makes it inefficient, so does having lots of people contributing to a mailing list (possibly even more so, since it's all too easy for email discussion to go off on a tangent). So while I am all in favour of making it as easy as possible for Council discussion to be read by as many people as possible, I think that contributions to it should come via our usual open route, i.e. TEI-L. As Paul notes (and I agree) there is no need to set up a separate "techie only" discussion list (and when we did it was a resounding failure, fwiw)

As to the role of ancient monuments like myself: when I come off Council, I fully intend to continue to scrutinize Council discussions and if so moved comment on them on TEI-L. I also expect to be continuing to tinker with ideas for improving the TEI Guidelines, which I will feed into the Council's deliberations. But I do not expect or desire to be given any special title or status as a result.

...

On 04/12/15 10:02, Magdalena Turska wrote: Hi,

As I see it, council list is publicly archived anyway, I don't expect allowing other people to join should raise any issues - anyone who's interested in reading can do it anyway, but list subscription would make it a lot easier to follow the discussion. The only 'danger' would be sudden high volume of traffic from outside of Council, but let's be realistic how likely is that. So I'd be all for opening the council list for anyone. Keeping separate contributors list is a great idea if you want to have one more dead list with 0 traffic on your mailserver :)

For telcos I do support the view that too much people makes them very inefficient, so unless there's a specific reason to invite someone, no point in doing that. For f2f though, especially if they happen to coincide with a conference some of you did say already that the open Council session in Lyon was a good experiment, so why not repeat it (with some disclaimer how many ppl max council can accommodate?).

As for pushing privileges or organization membership, I expect that once one someone gets it, there's no real need to revoke them just because someone's term on the Council has come to an end? To avoid misunderstanding we might skip the 'Council' tag altogether. As a side not for the repos, is there a policy already like 'let's only work via pull requests' or 'don't ever merge your own changes', to keep some level of peer review there?

All in all, the goal from my perspective is to keep as many ppl involved in active development and infrastructure maintenance as possible. Which is obviously hard as we all are busy with our dayjobs. So we shouldn't impose formal barriers for those rare specimens who might fancy devoting their private time to TEI.

Best,

Magdalena

...

On 4 December 2015 at 02:06, Paul Schaffner wrote:

I think I agree with most of this (I usually do agree with MH!) But am skeptical about a 'contributors' list'; I see no reason techie discussions should not take place on TEI-L, which is hardly prone to excessive traffic, where they would raise the general tone and educate, by osmosis.

pfs

...

On Thu, Dec 3, 2015, at 17:00, Martin Holmes wrote: Hi Hugh,

Thanks for getting all this going. I'm actually looking forward to being more active next year than I have been recently, because I'll no longer be the managing editor of the Journal, so I hope to be a good test case for staying involved.

I don't think contributors should attend telcos or FtFs except in rare cases where they might be brought in for part of a meeting to talk about a specific issue. As we discovered today, there are technical limitations on the number of participants in a telco, and in any case, when too many people are present, some folks inevitably become less willing or able to contribute (I'm thinking especially about people whose first language is not English, and might get lost when discussions get too voluble or too many people are speaking.)

I'm in two minds about whether contributors should remain on the mailing list. If it gets too large, discussions will become incoherent and inconclusive. There's the obvious issue of who decides who should be on it and who shouldn't. And the fact that this is the Council mailing list means that it should really only host Council deliberations.

There are some alternatives that might be workable, though. We could have a Contributors mailing list, to which one designated member of Council would subscribe for the purposes of acting as a bridge to Council (others might subscribe too if they're interested). This would have to be clearly distinguished in intent from the regular TEI-L; it would be for expert-level discussions, and perhaps restricted initially only to people who have been on Council, and who can therefore be expected to understand to some degree how the repos and build processes work. Alternatively, we might consider it also as a pathway onto Council; people might join that list and learn how to contribute and how things work, and then use their demonstrated willingness to contribute as a factor in their election run for Council. You could have a pathway such as:

- Read the list - Ask to join it and be added - Read documentation and learn about git etc. - Be assigned some straightforward tickets - Carry them out - Stand for Council in the next election

That would ease the transition onto Council as well as off. People who never got to the ticket stage, or who never completed tickets assigned to them, could be removed from the list after a specific period, presumably after learning that it's not for them.

There are other aspects of cycling off Council that need to be considered. I have credentials to access the tei-c.org server. Should I lose those? Ideally there should be a periodic review (perhaps once a year) of everyone holding such credentials, and the Council would decide whether they ought to continue to have them.

Cheers, Martin

...

On 15-12-03 01:37 PM, Hugh Cayless wrote: Dear All,

Thanks for the productive meeting earlier today. I’d said I wanted to broach the topic of keeping Contributors engaged over email, partly because it’s been a little contentious in the past and partly because I think it’s something that deserves more deliberation than we can give it in a single meeting. I’ll start by setting out how (as I understand it) things work now and then paint a picture of things as I’d like them to be. I mean the latter as something for you all to react to, so don’t hesitate to do so. I’d particularly like reactions from those of you who are new to Council. This is really going to be an ongoing conversation, I believe, and not something we can just fix. Martin has volunteered to be a champion for Contributors and I’m hoping that he and any other outgoing members who want to remain active participants will be vocal about what works and what doesn’t work for them. Council is a highly effective group that does a lot of good work, so we need to find a balance that doesn’t mess with our effectiveness and cohesiveness.

The status quo:

Engagement with TEI work happens via the TEI and Stylesheets repos on GitHub. Each of these has issue trackers, and there are two teams that have access to make changes to TEI, the Technical Council and "TEI Contributors". Incidentally, if the new folks will send me their github ids, I’ll add you to the Council team. The Tech Council team is for current Council members and the Contributors team is for a) former Council members who wish to remain active and b) anyone else we decide should have the ability to push directly to the TEI repo. This being GitHub, we can also take pull requests from people on neither team. Discussion of TEI stuff happens on this mailing list, on the issue trackers, in our monthly telecons, and in our Face to Face meeting. Only current Council members are on the mailing list, and people are removed as they cycle off Council. Only Council members attend the telecons and the F2F meetings, though occasionally "outside experts" are invited. Council tends to operate on consensus, though from time to time contentious issues are put to a vote.

My ideal world:

Contributors would be able to be as involved as they want to be in ongoing TEI development. That might include staying on or joining the mailing list, attending telecons, and even F2F meetings (though the TEI wouldn’t be able to pay for them unless they were formally invited of course). The main difference between Council Members and Contributors would be that the former have a vote when things come to a vote and would in general have more responsibility for development and maintenance.

I feel that we don’t do enough to foster an active community of people who are TEI experts, and I think part of that is Council being a bit mysterious and exclusionary. It’s hard to get onto Council, especially if you’re not already part of a community of TEI users (so that you have name recognition in the elections) and people who leave have tended to just drift away (often leaving unfinished business).

As I mentioned above, we’ve had a version of this discussion before, and I think mine was a minority view then, but I wanted to raise it again now to get the reactions of our incoming members and the perspectives of our outgoing members. What should we do? As you might have guessed, I have strong opinions, so I’m going to shut up for a while in the hope that a productive discussion develops without me driving it :-). -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived -- Paul Schaffner Digital Library Production Service PFSchaffner@umich.edu | http://www.umich.edu/~pfs/

-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

-- Dr James Cummings, James.Cummings@it.ox.ac.uk Academic IT Services, University of Oxford

-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

Hi all. Non-council contributors: We should establish them as a trusted group on both GitHub and add them to the council list. As Magdalena said, they won't be a huge number and they should be vetted and approved by the council. Lists: we shouldn't open the council list too much. We also often use it for relatively uninteresting tasks such as scheduling, telling people we'll be late, asking directions during a F2F... However, if you're a contributor on GitHub, then you should be on the list too. Calls and F2F: definitely limit this to council members only. We can invite contributors if one or more items on the agenda need their input. GitHub: I like what Magdalena asked: "is there a policy already like 'let's only work via pull requests' or 'don't ever merge your own changes', to keep some level of peer review there?". I really think this would be useful. Council members and collaborators should both be able to commit to GitHub, but should still send a Pull Request and another member would have to approve and merge it (ie don't merge you own contributions). This would make the process of fixing tickets equal for all (council, trusted contributors, external contributors), while restricting the power to merge to council and trusted contributors only. Re: Hugh's query, I'd say Hangout via Google Apps and if we go over the 15 people limit, we add the phone call. Raff On Fri, Dec 4, 2015 at 8:54 AM, Hugh Cayless wrote:

[Breaking silence just for this one issue] What to do about telecons is a problem, and something we'll have to deal with whether we have extra people on the call or not. At our full strength, we'll still be too much for Google Hangouts. We switched to them last year because a couple of folks had trouble dialing in to the phone conference from work, but we may never have actually hit the limit, because not everyone made it to every call. We have several options, and all of them have upsides and downsides:

1) Keep using just Google. We get video, which is nice. Setup is super easy. Stefan tells me that Google Apps accounts get 15 on a video chat instead of 10. We'd have to have someone with an Apps account initiate the call to get that. Some of you may have one through your workplace.

2) Use Google and call into the phone conference. This means the first 9 people get video and the others have to call in via phone. This has the advantage of allowing people to join by phone, which is actually very convenient if you're not somewhere with wifi. It does mean keeping track of the phone conferencing details and me remembering to remind everyone beforehand. It also means there'll be extra churn at the start of meetings as people figure out how to join and it's a pain for the person initiating the call (generally me) because I have to call in to the phone conference from both my computer and my phone, to stop it playing hold music at the rest of us (it does this when there's only one person in the phone chat).

3) Go back to phone conference only. It's perfectly possible to dial in using Skype or Google if you want it on your computer (you may incur charges for doing so, of course). Unlimited participants. No video. Can be hard to tell who's speaking until you're very familiar with people's voices. Have to keep track of call-in details. Have to have a phone line available to you. Kind of a pain in the ass, but very reliable.

4) Other videoconferencing services. a) We tried Skype last year, and it's not very reliable, especially as you add more participants. b) Someone recommended talky.io to me, which claims 15 participants and seems to be free. No idea about reliability. We could try it next time and see if it works. c) There are for-pay services like webex. I think I can get a webex account through Duke. It's free for VOIP and fairly cheap for phone-in participants. I could probably get Duke to cover the costs. It would be dependent on me though, obviously, so only good as long as I'm on Council. Could maybe get TEI to get an account. Cost would be <$500 USD per year plus phone charges if any.

On Fri, Dec 4, 2015 at 8:04 AM, Elisa wrote:

...

Dear Hugh and Council-in-Transition, I'm of a couple of minds here: First, I thought one of the roles of Council members was to monitor and respond to questions on the TEI-L list, and to field that list for new ticket items. Since that seems to me our most active and visible community role, it seems important to recruit for Council and stay connected to past Council members there. But what about the actual assigning of tickets and doing specialized work that Council doesn't discuss much with the wider community--like updating a Jenkins box (for an example)? I didn't know much at all about these until I attended a first Council meeting in Lyon, and I could see how the interests of supporting infrastructure wouldn't easily be introduced on TEI-L. And they are of immediate interest to the Technical Council.

Maybe we should make this a matter of Decision (following the spirit of Lou's response) for the outgoing members and the Council together: Ongoing Council members know the issues and range of open tickets best and have to orient new members to them, and it seems to me (just getting started here) that there's Much for us new people to do and learn. It looks to me as if Council itself as a group easily identifies outgoing members who want to stay active based on their expertise and interests, and in that case, Council can decide to introduce these people to Council as active Contributors who will stay around on GitHub and remain on the Council mailing list to advise and update. How long will a Contributor remain active? Council itself will be able to monitor that, and perhaps as an order of business each year can decide to check in with Contributors who haven't been heard from in a while and drop from the Council list when they are quiet.

As I think about this, I would really appreciate the benefit of consulting with anyone knowledgeable about the range of technical work that I've not seen discussed on the TEI-L. That's where I've learned a lot too, but that list just doesn't cover a lot of what Council actually does.

I think I agree with what others are saying here, that Contributors can't easily be part of meetings, but might be invited to present there. But Contributors I think should continue on the Council list, AND Council itself ought to be as active as possible to educate the TEI-list. Introducing a third list might introduce confusion and inefficiency.

Whether potential new recruits for Council could be recognized and given Contributor roles (like what Martin describes) seems potentially more vexed--and not quite the same thing since these people would not be knowledgeable of Council processes and decision-making as outgoing Councillors are. I like the idea of mentoring toward Council election (and that would be a powerful thing to be able to state on a candidate nomination statement)--but I think that too should be a matter of decision by Council (so we all know everyone involved with tickets) and such Mentees or Understudies will definitely want to be part of the Council mailing list.

I may not understand this well yet, but is there anything especially confidential in Council list content? If not, we might well just want it to be open to anyone to subscribe in the interests of transparency--and periodically invite TEI-L members to join as they wish. Those who join are likely the kinds of people who'd want to run for Council. I think the actual work of the tickets is something we need to make sure is being done by people knowledgeable and in the loop on Council decisions. So in a Council meeting, we want to review together Who's doing What, and make sure we're all clear and in agreement on what work is best handled by Contributors and fine to delegate to Mentees.

On GitHub, I'm ebeshero , and happy to be on the Council with you all!

Best, Elisa

Sent from my iPad

...

On Dec 4, 2015, at 6:56 AM, James Cummings

wrote:

...

Hi all,

I can see benefits and drawbacks on both sides, but generally agree

with Lou's point of view below.

...

I think only Council (and ppl like webmaster) should be on the council

...

I like Magdalena's idea of not necessarily distinguishing between Council and other Trusted Developers on github, but if both have the same github privileges, then it doesn't really bother me if there such a distinction. I am actively against the idea of a TEI-tech mailing list (it has been suggested before and as Lou notes wasn't successful). I learned my TEI mostly from 1999-2003 by eavesdropping on the TEI-L mailing list and asking

...

I also agree that Lou shouldn't be given any special title or status when he departs council. ;-) He knows he already has that in our hearts.

-James

...

On 04/12/15 10:16, Lou Burnard wrote: I don't think anyone's arguing against widening access to the Council's deliberations. However, I do think that an important, possibly the most important,. thing the Council does (eventually) is MAKE DECISIONS. In

...

...

As to the role of ancient monuments like myself: when I come off

Council, I fully intend to continue to scrutinize Council discussions and if so moved comment on them on TEI-L. I also expect to be continuing to tinker with ideas for improving the TEI Guidelines, which I will feed into

...

...

...

On 04/12/15 10:02, Magdalena Turska wrote: Hi,

As I see it, council list is publicly archived anyway, I don't expect allowing other people to join should raise any issues - anyone who's interested in reading can do it anyway, but list subscription would

make it

...

...

a lot easier to follow the discussion. The only 'danger' would be sudden high volume of traffic from outside of Council, but let's be realistic how likely is that. So I'd be all for opening the council list for anyone. Keeping separate contributors list is a great idea if you want to have one more dead list with 0 traffic on your mailserver :)

For telcos I do support the view that too much people makes them very inefficient, so unless there's a specific reason to invite someone, no point in doing that. For f2f though, especially if they happen to coincide with a conference some of you did say already that the open Council session in Lyon was a good experiment, so why not repeat it (with some disclaimer how many ppl max council can accommodate?).

As for pushing privileges or organization membership, I expect that once one someone gets it, there's no real need to revoke them just because someone's term on the Council has come to an end? To avoid misunderstanding we might skip the 'Council' tag altogether. As a side not for the repos, is there a policy already like 'let's only work via pull requests' or 'don't ever merge your own changes', to keep some level of peer review there?

All in all, the goal from my perspective is to keep as many ppl involved in active development and infrastructure maintenance as possible. Which is obviously hard as we all are busy with our dayjobs. So we shouldn't impose formal barriers for those rare specimens who might fancy devoting

...

...

...

private time to TEI.

Best,

Magdalena

...

On 4 December 2015 at 02:06, Paul Schaffner wrote:

I think I agree with most of this (I usually do agree with MH!) But am skeptical about a 'contributors' list'; I see no reason techie discussions should not take place on TEI-L, which is hardly prone to excessive traffic, where they would raise the general tone and educate, by osmosis.

pfs

> On Thu, Dec 3, 2015, at 17:00, Martin Holmes wrote: > Hi Hugh, > > Thanks for getting all this going. I'm actually looking forward to being > more active next year than I have been recently, because I'll no longer > be the managing editor of the Journal, so I hope to be a good test case > for staying involved. > > I don't think contributors should attend telcos or FtFs except in rare > cases where they might be brought in for part of a meeting to talk about > a specific issue. As we discovered today, there are technical > limitations on the number of participants in a telco, and in any case, > when too many people are present, some folks inevitably become less > willing or able to contribute (I'm thinking especially about people > whose first language is not English, and might get lost when discussions > get too voluble or too many people are speaking.) > > I'm in two minds about whether contributors should remain on the mailing > list. If it gets too large, discussions will become incoherent and > inconclusive. There's the obvious issue of who decides who should be on > it and who shouldn't. And the fact that this is the Council mailing

...

...

...

...

> means that it should really only host Council deliberations. > > There are some alternatives that might be workable, though. We could > have a Contributors mailing list, to which one designated member of > Council would subscribe for the purposes of acting as a bridge to > Council (others might subscribe too if they're interested). This would > have to be clearly distinguished in intent from the regular TEI-L; it > would be for expert-level discussions, and perhaps restricted initially > only to people who have been on Council, and who can therefore be > expected to understand to some degree how the repos and build

...

...

...

...

> work. Alternatively, we might consider it also as a pathway onto > Council; people might join that list and learn how to contribute and how > things work, and then use their demonstrated willingness to contribute > as a factor in their election run for Council. You could have a

...

...

...

...

> such as: > > - Read the list > - Ask to join it and be added > - Read documentation and learn about git etc. > - Be assigned some straightforward tickets > - Carry them out > - Stand for Council in the next election > > That would ease the transition onto Council as well as off. People who > never got to the ticket stage, or who never completed tickets assigned > to them, could be removed from the list after a specific period, > presumably after learning that it's not for them. > > There are other aspects of cycling off Council that need to be > considered. I have credentials to access the tei-c.org server. Should I > lose those? Ideally there should be a periodic review (perhaps once a > year) of everyone holding such credentials, and the Council would decide > whether they ought to continue to have them. > > Cheers, > Martin > >> On 15-12-03 01:37 PM, Hugh Cayless wrote: >> Dear All, >> >> Thanks for the productive meeting earlier today. I’d said I wanted to >> broach the topic of keeping Contributors engaged over email,

...

...

...

...

>> because it’s been a little contentious in the past and partly because >> I think it’s something that deserves more deliberation than we can >> give it in a single meeting. I’ll start by setting out how (as I >> understand it) things work now and then paint a picture of things as >> I’d like them to be. I mean the latter as something for you all to >> react to, so don’t hesitate to do so. I’d particularly like reactions >> from those of you who are new to Council. This is really going to be >> an ongoing conversation, I believe, and not something we can just >> fix. Martin has volunteered to be a champion for Contributors and I’m >> hoping that he and any other outgoing members who want to remain >> active participants will be vocal about what works and what doesn’t >> work for them. Council is a highly effective group that does a lot of >> good work, so we need to find a balance that doesn’t mess with our >> effectiveness and cohesiveness. >> >> The status quo: >> >> Engagement with TEI work happens via the TEI and Stylesheets repos on >> GitHub. Each of these has issue trackers, and there are two teams >> that have access to make changes to TEI, the Technical Council and >> "TEI Contributors". Incidentally, if the new folks will send me

...

...

...

...

>> github ids, I’ll add you to the Council team. The Tech Council team >> is for current Council members and the Contributors team is for a) >> former Council members who wish to remain active and b) anyone else >> we decide should have the ability to push directly to the TEI repo. >> This being GitHub, we can also take pull requests from people on >> neither team. Discussion of TEI stuff happens on this mailing

...

...

...

...

>> on the issue trackers, in our monthly telecons, and in our Face to >> Face meeting. Only current Council members are on the mailing

...

...

...

...

>> and people are removed as they cycle off Council. Only Council >> members attend the telecons and the F2F meetings, though occasionally >> "outside experts" are invited. Council tends to operate on consensus, >> though from time to time contentious issues are put to a vote. >> >> My ideal world: >> >> Contributors would be able to be as involved as they want to be in >> ongoing TEI development. That might include staying on or joining

...

...

...

...

>> mailing list, attending telecons, and even F2F meetings (though

list since it is an open but elected body. people lots of stupid questions. I learned it even more when I started trying to answer questions. I'm sure I still have a lot more to learn. The technical conversations there are easily ignored by users who are not interested and raise the technical literacy of the community for those who do eavesdrop. (And by technical literacy here I mean specifically of the TEI infrastructure.) Indeed, I'd encourage Council to have _more_ technical discussions on TEI-L when we're discussing a particular ticket/issue so as to involve the wider community more regularly. I.e. the council list should be for council business (which includes making the decisions) but general discussion of issues that are potentially of interest to a wider audience we could include more people. that sense it is not just a general discussion forum: it is also an executive. Which is why I would vote against blurring the distinction between the Council and the body of people supervising, criticising, or even contributing to those decisions. If having lots of people in a telco makes it inefficient, so does having lots of people contributing to a mailing list (possibly even more so, since it's all too easy for email discussion to go off on a tangent). So while I am all in favour of making it as easy as possible for Council discussion to be read by as many people as possible, I think that contributions to it should come via our usual open route, i.e. TEI-L. As Paul notes (and I agree) there is no need to set up a separate "techie only" discussion list (and when we did it was a resounding failure, fwiw) the Council's deliberations. But I do not expect or desire to be given any special title or status as a result. their list processes pathway partly their list, list, the the

...

...

...

...

>> TEI wouldn’t be able to pay for them unless they were formally >> invited of course). The main difference between Council Members and >> Contributors would be that the former have a vote when things come to >> a vote and would in general have more responsibility for development >> and maintenance. >> >> I feel that we don’t do enough to foster an active community of >> people who are TEI experts, and I think part of that is Council being >> a bit mysterious and exclusionary. It’s hard to get onto Council, >> especially if you’re not already part of a community of TEI users (so >> that you have name recognition in the elections) and people who leave >> have tended to just drift away (often leaving unfinished business). >> >> As I mentioned above, we’ve had a version of this discussion before, >> and I think mine was a minority view then, but I wanted to raise it >> again now to get the reactions of our incoming members and the >> perspectives of our outgoing members. What should we do? As you might >> have guessed, I have strong opinions, so I’m going to shut up for a >> while in the hope that a productive discussion develops without me >> driving it :-). > -- > tei-council mailing list > tei-council@lists.tei-c.org > http://lists.lists.tei-c.org/mailman/listinfo/tei-council > > PLEASE NOTE: postings to this list are publicly archived -- Paul Schaffner Digital Library Production Service PFSchaffner@umich.edu | http://www.umich.edu/~pfs/

-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

-- Dr James Cummings, James.Cummings@it.ox.ac.uk Academic IT Services, University of Oxford

-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

Hi all, Thanks for the thoughtful feedback on this. I'm now convinced that the idea of a separate mailing list for Contributors is a bad one, but I still don't think the likes of me should stay on the Council list after leaving. As James says, the Council has executive functions, and if people who don't have that power vested in them are involved in the discussions, there will be confusion and less chance of reaching a consensus. I think on balance, using TEI-L instead has benefits. In earlier discussions on this, Hugh raised the point that in order to get time to contribute, many people will need to be able to demonstrate to their institution that they are in some way vetted and trusted, and have some sort of semi-official role in the project. That's not so much of a concern for me, but it will be for others; if the existence of the "Contributors" group on GitHub is sufficient to answer that need, then great, but otherwise we might want to think about another mechanism. In theory I'm also in favour of everyone-must-issue-pull-requests, but in practice I fear even more confusion since this (correct me if I'm wrong) involves forking, and forking is different from branching, and will need a bit more training and documentation for those of us coming from svn. Cheers, Martin On 15-12-04 12:56 PM, Scholger, Martina (martina.scholger@uni-graz.at) wrote:

Hi all,

I don't really have anything new to add, but nevertheless want to contribute to the ongoing discussion...

I think that outgoing members, who already have the trust of the community through their previous election, should be able to remain on the Council list and on Github, if they themselves want to contribute further and have the spare time.

Regarding the telcos: the more people, the harder it will be to follow the discussion, to come to decisions or to notice if somebody lost the connection... i would therefor also keep the telcos to actual Council members. If it works with a video call that would be fine, google apps sounds like a good solution for now.

The open meeting in Lyon was a great way to get an idea how the councils work looks like. It is also a good opportunity for nominees to get to know the council members personally.

I also find the peer reviewing of changes, as Magdalena and Raffaele mentioned, a good idea.

Best, Martina

Von meinem iPad gesendet

...

Am 04.12.2015 um 17:26 schrieb "Raffaele Viglianti" :

Hi all.

Non-council contributors: We should establish them as a trusted group on both GitHub and add them to the council list. As Magdalena said, they won't be a huge number and they should be vetted and approved by the council.

Lists: we shouldn't open the council list too much. We also often use it for relatively uninteresting tasks such as scheduling, telling people we'll be late, asking directions during a F2F... However, if you're a contributor on GitHub, then you should be on the list too.

Calls and F2F: definitely limit this to council members only. We can invite contributors if one or more items on the agenda need their input.

GitHub: I like what Magdalena asked: "is there a policy already like 'let's only work via pull requests' or 'don't ever merge your own changes', to keep some level of peer review there?". I really think this would be useful. Council members and collaborators should both be able to commit to GitHub, but should still send a Pull Request and another member would have to approve and merge it (ie don't merge you own contributions). This would make the process of fixing tickets equal for all (council, trusted contributors, external contributors), while restricting the power to merge to council and trusted contributors only.

Re: Hugh's query, I'd say Hangout via Google Apps and if we go over the 15 people limit, we add the phone call.

Raff

...

On Fri, Dec 4, 2015 at 8:54 AM, Hugh Cayless wrote:

[Breaking silence just for this one issue] What to do about telecons is a problem, and something we'll have to deal with whether we have extra people on the call or not. At our full strength, we'll still be too much for Google Hangouts. We switched to them last year because a couple of folks had trouble dialing in to the phone conference from work, but we may never have actually hit the limit, because not everyone made it to every call. We have several options, and all of them have upsides and downsides:

1) Keep using just Google. We get video, which is nice. Setup is super easy. Stefan tells me that Google Apps accounts get 15 on a video chat instead of 10. We'd have to have someone with an Apps account initiate the call to get that. Some of you may have one through your workplace.

2) Use Google and call into the phone conference. This means the first 9 people get video and the others have to call in via phone. This has the advantage of allowing people to join by phone, which is actually very convenient if you're not somewhere with wifi. It does mean keeping track of the phone conferencing details and me remembering to remind everyone beforehand. It also means there'll be extra churn at the start of meetings as people figure out how to join and it's a pain for the person initiating the call (generally me) because I have to call in to the phone conference from both my computer and my phone, to stop it playing hold music at the rest of us (it does this when there's only one person in the phone chat).

3) Go back to phone conference only. It's perfectly possible to dial in using Skype or Google if you want it on your computer (you may incur charges for doing so, of course). Unlimited participants. No video. Can be hard to tell who's speaking until you're very familiar with people's voices. Have to keep track of call-in details. Have to have a phone line available to you. Kind of a pain in the ass, but very reliable.

4) Other videoconferencing services. a) We tried Skype last year, and it's not very reliable, especially as you add more participants. b) Someone recommended talky.io to me, which claims 15 participants and seems to be free. No idea about reliability. We could try it next time and see if it works. c) There are for-pay services like webex. I think I can get a webex account through Duke. It's free for VOIP and fairly cheap for phone-in participants. I could probably get Duke to cover the costs. It would be dependent on me though, obviously, so only good as long as I'm on Council. Could maybe get TEI to get an account. Cost would be <$500 USD per year plus phone charges if any.

...

On Fri, Dec 4, 2015 at 8:04 AM, Elisa wrote:

Dear Hugh and Council-in-Transition, I'm of a couple of minds here: First, I thought one of the roles of Council members was to monitor and respond to questions on the TEI-L list, and to field that list for new ticket items. Since that seems to me our most active and visible community role, it seems important to recruit for Council and stay connected to past Council members there. But what about the actual assigning of tickets and doing specialized work that Council doesn't discuss much with the wider community--like updating a Jenkins box (for an example)? I didn't know much at all about these until I attended a first Council meeting in Lyon, and I could see how the interests of supporting infrastructure wouldn't easily be introduced on TEI-L. And they are of immediate interest to the Technical Council.

Maybe we should make this a matter of Decision (following the spirit of Lou's response) for the outgoing members and the Council together: Ongoing Council members know the issues and range of open tickets best and have to orient new members to them, and it seems to me (just getting started here) that there's Much for us new people to do and learn. It looks to me as if Council itself as a group easily identifies outgoing members who want to stay active based on their expertise and interests, and in that case, Council can decide to introduce these people to Council as active Contributors who will stay around on GitHub and remain on the Council mailing list to advise and update. How long will a Contributor remain active? Council itself will be able to monitor that, and perhaps as an order of business each year can decide to check in with Contributors who haven't been heard from in a while and drop from the Council list when they are quiet.

As I think about this, I would really appreciate the benefit of consulting with anyone knowledgeable about the range of technical work that I've not seen discussed on the TEI-L. That's where I've learned a lot too, but that list just doesn't cover a lot of what Council actually does.

I think I agree with what others are saying here, that Contributors can't easily be part of meetings, but might be invited to present there. But Contributors I think should continue on the Council list, AND Council itself ought to be as active as possible to educate the TEI-list. Introducing a third list might introduce confusion and inefficiency.

Whether potential new recruits for Council could be recognized and given Contributor roles (like what Martin describes) seems potentially more vexed--and not quite the same thing since these people would not be knowledgeable of Council processes and decision-making as outgoing Councillors are. I like the idea of mentoring toward Council election (and that would be a powerful thing to be able to state on a candidate nomination statement)--but I think that too should be a matter of decision by Council (so we all know everyone involved with tickets) and such Mentees or Understudies will definitely want to be part of the Council mailing list.

I may not understand this well yet, but is there anything especially confidential in Council list content? If not, we might well just want it to be open to anyone to subscribe in the interests of transparency--and periodically invite TEI-L members to join as they wish. Those who join are likely the kinds of people who'd want to run for Council. I think the actual work of the tickets is something we need to make sure is being done by people knowledgeable and in the loop on Council decisions. So in a Council meeting, we want to review together Who's doing What, and make sure we're all clear and in agreement on what work is best handled by Contributors and fine to delegate to Mentees.

On GitHub, I'm ebeshero , and happy to be on the Council with you all!

Best, Elisa

Sent from my iPad

...

On Dec 4, 2015, at 6:56 AM, James Cummings

wrote:

...

Hi all,

I can see benefits and drawbacks on both sides, but generally agree

with Lou's point of view below.

...

I think only Council (and ppl like webmaster) should be on the council

...

I like Magdalena's idea of not necessarily distinguishing between Council and other Trusted Developers on github, but if both have the same github privileges, then it doesn't really bother me if there such a distinction. I am actively against the idea of a TEI-tech mailing list (it has been suggested before and as Lou notes wasn't successful). I learned my TEI mostly from 1999-2003 by eavesdropping on the TEI-L mailing list and asking

...

I also agree that Lou shouldn't be given any special title or status when he departs council. ;-) He knows he already has that in our hearts.

-James

...

On 04/12/15 10:16, Lou Burnard wrote: I don't think anyone's arguing against widening access to the Council's deliberations. However, I do think that an important, possibly

...

...

As to the role of ancient monuments like myself: when I come off

Council, I fully intend to continue to scrutinize Council discussions and if so moved comment on them on TEI-L. I also expect to be continuing to tinker with ideas for improving the TEI Guidelines, which I will feed into

...

...

> On 04/12/15 10:02, Magdalena Turska wrote: Hi, > > As I see it, council list is publicly archived anyway, I > don't expect allowing other people to join should raise > any issues - anyone who's interested in reading can do it > anyway, but list subscription would

make it

...

> a lot easier to follow the discussion. The only 'danger' > would be sudden > high volume of traffic from outside of Council, but let's > be realistic how > likely is that. So I'd be all for opening the council > list for anyone. > Keeping separate contributors list is a great idea if you > want to have one > more dead list with 0 traffic on your mailserver :) > > For telcos I do support the view that too much people > makes them very inefficient, so unless there's a specific > reason to invite someone, no > point in doing that. For f2f though, especially if they > happen to coincide > with a conference some of you did say already that the > open Council session > in Lyon was a good experiment, so why not repeat it (with > some disclaimer > how many ppl max council can accommodate?). > > As for pushing privileges or organization membership, I > expect that once > one someone gets it, there's no real need to revoke them > just because someone's term on the Council has come to an > end? To avoid misunderstanding > we might skip the 'Council' tag altogether. As a side not > for the repos, is there a policy already like 'let's only > work via pull requests' or 'don't ever merge your own > changes', to keep > some level of peer review there? > > All in all, the goal from my perspective is to keep as > many ppl involved in > active development and infrastructure maintenance as > possible. Which is > obviously hard as we all are busy with our dayjobs. So we > shouldn't impose > formal barriers for those rare specimens who might fancy > devoting

...

...

> private time to TEI. > > Best, > > Magdalena > >> On 4 December 2015 at 02:06, Paul Schaffner >> wrote: >> >> I think I agree with most of this (I usually do agree >> with MH!) But am skeptical about a 'contributors' >> list'; I see no reason techie >> discussions should not take place on TEI-L, which is >> hardly prone to excessive traffic, where they would >> raise the general tone and educate, by osmosis. >> >> pfs >> >>> On Thu, Dec 3, 2015, at 17:00, Martin Holmes wrote: >>> Hi Hugh, >>> >>> Thanks for getting all this going. I'm actually >>> looking forward to being >>> more active next year than I have been recently, >>> because I'll no longer >>> be the managing editor of the Journal, so I hope to >>> be a good test case >>> for staying involved. >>> >>> I don't think contributors should attend telcos or >>> FtFs except in rare >>> cases where they might be brought in for part of a >>> meeting to talk about >>> a specific issue. As we discovered today, there are >>> technical limitations on the number of participants >>> in a telco, and in any case, >>> when too many people are present, some folks >>> inevitably become less willing or able to contribute >>> (I'm thinking especially about people whose first >>> language is not English, and might get lost when discussions >>> get too voluble or too many people are speaking.) >>> >>> I'm in two minds about whether contributors should >>> remain on the mailing >>> list. If it gets too large, discussions will become >>> incoherent and inconclusive. There's the obvious >>> issue of who decides who should be on >>> it and who shouldn't. And the fact that this is the >>> Council mailing

...

...

>>> means that it should really only host Council >>> deliberations. >>> >>> There are some alternatives that might be workable, >>> though. We could >>> have a Contributors mailing list, to which one >>> designated member of Council would subscribe for the >>> purposes of acting as a bridge to Council (others >>> might subscribe too if they're interested). This would >>> have to be clearly distinguished in intent from the >>> regular TEI-L; it >>> would be for expert-level discussions, and perhaps >>> restricted initially >>> only to people who have been on Council, and who can >>> therefore be expected to understand to some degree >>> how the repos and build

...

...

>>> work. Alternatively, we might consider it also as a >>> pathway onto Council; people might join that list and >>> learn how to contribute and how >>> things work, and then use their demonstrated >>> willingness to contribute >>> as a factor in their election run for Council. You >>> could have a

...

...

>>> such as: >>> >>> - Read the list - Ask to join it and be added - Read >>> documentation and learn about git etc. - Be assigned >>> some straightforward tickets - Carry them out - Stand >>> for Council in the next election >>> >>> That would ease the transition onto Council as well >>> as off. People who >>> never got to the ticket stage, or who never completed >>> tickets assigned >>> to them, could be removed from the list after a >>> specific period, presumably after learning that it's >>> not for them. >>> >>> There are other aspects of cycling off Council that >>> need to be considered. I have credentials to access >>> the tei-c.org server. Should I >>> lose those? Ideally there should be a periodic review >>> (perhaps once a >>> year) of everyone holding such credentials, and the >>> Council would decide >>> whether they ought to continue to have them. >>> >>> Cheers, Martin >>> >>>> On 15-12-03 01:37 PM, Hugh Cayless wrote: Dear >>>> All, >>>> >>>> Thanks for the productive meeting earlier today. >>>> I'd said I wanted to >>>> broach the topic of keeping Contributors engaged >>>> over email,

...

...

>>>> because it's been a little contentious in the past >>>> and partly because >>>> I think it's something that deserves more >>>> deliberation than we can give it in a single >>>> meeting. I'll start by setting out how (as I >>>> understand it) things work now and then paint a >>>> picture of things as >>>> I'd like them to be. I mean the latter as something >>>> for you all to react to, so don't hesitate to do >>>> so. I'd particularly like reactions >>>> from those of you who are new to Council. This is >>>> really going to be >>>> an ongoing conversation, I believe, and not >>>> something we can just fix. Martin has volunteered >>>> to be a champion for Contributors and I'm >>>> hoping that he and any other outgoing members who >>>> want to remain active participants will be vocal >>>> about what works and what doesn't >>>> work for them. Council is a highly effective group >>>> that does a lot of >>>> good work, so we need to find a balance that >>>> doesn't mess with our effectiveness and >>>> cohesiveness. >>>> >>>> The status quo: >>>> >>>> Engagement with TEI work happens via the TEI and >>>> Stylesheets repos on >>>> GitHub. Each of these has issue trackers, and there >>>> are two teams that have access to make changes to >>>> TEI, the Technical Council and "TEI Contributors". >>>> Incidentally, if the new folks will send me

...

...

>>>> github ids, I'll add you to the Council team. The >>>> Tech Council team >>>> is for current Council members and the Contributors >>>> team is for a) former Council members who wish to >>>> remain active and b) anyone else >>>> we decide should have the ability to push directly >>>> to the TEI repo. >>>> This being GitHub, we can also take pull requests >>>> from people on neither team. Discussion of TEI >>>> stuff happens on this mailing

...

...

>>>> on the issue trackers, in our monthly telecons, and >>>> in our Face to Face meeting. Only current Council >>>> members are on the mailing

...

...

>>>> and people are removed as they cycle off Council. >>>> Only Council members attend the telecons and the >>>> F2F meetings, though occasionally >>>> "outside experts" are invited. Council tends to >>>> operate on consensus, >>>> though from time to time contentious issues are put >>>> to a vote. >>>> >>>> My ideal world: >>>> >>>> Contributors would be able to be as involved as >>>> they want to be in ongoing TEI development. That >>>> might include staying on or joining

...

...

>>>> mailing list, attending telecons, and even F2F >>>> meetings (though

list since it is an open but elected body. people lots of stupid questions. I learned it even more when I started trying to answer questions. I'm sure I still have a lot more to learn. The technical conversations there are easily ignored by users who are not interested and raise the technical literacy of the community for those who do eavesdrop. (And by technical literacy here I mean specifically of the TEI infrastructure.) Indeed, I'd encourage Council to have _more_ technical discussions on TEI-L when we're discussing a particular ticket/issue so as to involve the wider community more regularly. I.e. the council list should be for council business (which includes making the decisions) but general discussion of issues that are potentially of interest to a wider audience we could include more people. the most important,. thing the Council does (eventually) is MAKE DECISIONS. In that sense it is not just a general discussion forum: it is also an executive. Which is why I would vote against blurring the distinction between the Council and the body of people supervising, criticising, or even contributing to those decisions. If having lots of people in a telco makes it inefficient, so does having lots of people contributing to a mailing list (possibly even more so, since it's all too easy for email discussion to go off on a tangent). So while I am all in favour of making it as easy as possible for Council discussion to be read by as many people as possible, I think that contributions to it should come via our usual open route, i.e. TEI-L. As Paul notes (and I agree) there is no need to set up a separate "techie only" discussion list (and when we did it was a resounding failure, fwiw) the Council's deliberations. But I do not expect or desire to be given any special title or status as a result. their list processes pathway partly their list, list, the the

...

...

>>>> TEI wouldn't be able to pay for them unless they >>>> were formally invited of course). The main >>>> difference between Council Members and >>>> Contributors would be that the former have a vote >>>> when things come to >>>> a vote and would in general have more >>>> responsibility for development >>>> and maintenance. >>>> >>>> I feel that we don't do enough to foster an active >>>> community of people who are TEI experts, and I >>>> think part of that is Council being >>>> a bit mysterious and exclusionary. It's hard to get >>>> onto Council, especially if you're not already part >>>> of a community of TEI users (so >>>> that you have name recognition in the elections) >>>> and people who leave >>>> have tended to just drift away (often leaving >>>> unfinished business). >>>> >>>> As I mentioned above, we've had a version of this >>>> discussion before, >>>> and I think mine was a minority view then, but I >>>> wanted to raise it >>>> again now to get the reactions of our incoming >>>> members and the perspectives of our outgoing >>>> members. What should we do? As you might >>>> have guessed, I have strong opinions, so I'm going >>>> to shut up for a >>>> while in the hope that a productive discussion >>>> develops without me driving it :-). >>> -- tei-council mailing list >>> tei-council@lists.tei-c.org >>> http://lists.lists.tei-c.org/mailman/listinfo/tei-council >>> >>> >>> PLEASE NOTE: postings to this list are publicly archived >> -- Paul Schaffner Digital Library Production Service >> PFSchaffner@umich.edu | http://www.umich.edu/~pfs/ >> >> >> -- tei-council mailing list >> tei-council@lists.tei-c.org >> http://lists.lists.tei-c.org/mailman/listinfo/tei-council >> >> >> PLEASE NOTE: postings to this list are publicly archived

-- Dr James Cummings, James.Cummings@it.ox.ac.uk Academic IT Services, University of Oxford

-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

If going back to using a paid-for service then surely the preference would be for the one that the Board already uses which JohnU has an account set up and bills him directly? My recollection was that it was cheap. -James On 05/12/15 01:50, Kevin Hawkins wrote:

On 12/4/15 7:54 AM, Hugh Cayless wrote:

...

4) Other videoconferencing services. a) We tried Skype last year, and it's not very reliable, especially as you add more participants. b) Someone recommended talky.io to me, which claims 15 participants and seems to be free. No idea about reliability. We could try it next time and see if it works. c) There are for-pay services like webex. I think I can get a webex account through Duke. It's free for VOIP and fairly cheap for phone-in participants. I could probably get Duke to cover the costs. It would be dependent on me though, obviously, so only good as long as I'm on Council. Could maybe get TEI to get an account. Cost would be <$500 USD per year plus phone charges if any.

Option (4d) might be https://www.freeconferencecall.com/ . Haven't used it, but it claims to allow up to 1,000 callers.

-- Dr James Cummings, James.Cummings@it.ox.ac.uk Academic IT Services, University of Oxford

I've now pushed a new version of the P5 pure ODD branch up, as lb42-pureodd-2 This one was made by re-cloning from dev, and then re-applying the changes I made for lb42-pureodd, so it ought to work. Alas, it doesn't, or not for me at any rate: I am seeing lots of errors in the generated RelaxNG seemingly caused by something not correctly processing dataRef elements. I'll keep on looking, but if someone else could just check that they have this problem too (just checkout the lb42-pureodd-2 branch, and then run the P5/Makefile) it would be helpful. The older branch, lb42-pureodd works just fine, of course. Grrrr.

It has to be something weird in my local installation then. Good. Demmed if I can see what it is though For me it breaks like this: BUILD: Generate modular DTDs, Schemas, Schematron and miscellaneous outputs ANT_OPTS="-Xss2m -Xmx752m -Djava.awt.headless=true" ant -q -lib Utilities/lib/jing.jar:Utilities/lib/saxon9he.jar -f antbuilder.xml -DXSL=/home/lou/Public/Stylesheets -DDRIVER=Source/guidelines-en.xml -Dverbose=yes base subset outputs [echo] make modular DTDs, RELAXNG schemas, json, odd schemas, schematron files [echo] Using /home/lou/Public/Stylesheets for XSL stylesheets [echo] Do ODD processing for p5odds.odd [echo] Do ODD processing for p5odds-examples.odd BUILD SUCCESSFUL Total time: 29 seconds BUILD: Generate modular RELAX NG (compact) schemas using trang (cd Schema; for i in *rng; do java -jar ../Utilities/lib/trang.jar $i `basename $i .rng`.rnc;done) /home/lou/Public/TEI/P5/Schema/analysis.rng:16:28: error: missing children /home/lou/Public/TEI/P5/Schema/certainty.rng:74:28: error: missing children /home/lou/Public/TEI/P5/Schema/core.rng:292:28: error: missing children .... etc etc On 04/12/15 14:56, Hugh Cayless wrote:

Seems to work for me. I don't have the full build running yet on my work machine, but it does the various RNG schemas in Exemplars just fine. Where is it breaking for you?

On Fri, Dec 4, 2015 at 8:42 AM, Lou Burnard wrote:

...

I've now pushed a new version of the P5 pure ODD branch up, as lb42-pureodd-2

This one was made by re-cloning from dev, and then re-applying the changes I made for lb42-pureodd, so it ought to work. Alas, it doesn't, or not for me at any rate: I am seeing lots of errors in the generated RelaxNG seemingly caused by something not correctly processing dataRef elements. I'll keep on looking, but if someone else could just check that they have this problem too (just checkout the lb42-pureodd-2 branch, and then run the P5/Makefile) it would be helpful.

The older branch, lb42-pureodd works just fine, of course. Grrrr.

-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived