Re: [tei-council] Contributors

4 Dec 2015

      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