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 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 -- 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