Re: Possible new Real-Time Applications and Infrastucture (RAI)Area

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Thanks David.  Please see inline:

At 05:49 PM 9/21/2005, David Kessens wrote:

Lakshminath,

On Wed, Sep 21, 2005 at 02:35:21PM -0700, Lakshminath Dondeti wrote:
>
> I am curious about the scheduling issues. If the IESG job is a "full-time" > job, why can't the people on IESG find time to meet with each other, f2f or > in telecons; perhaps someone will help me understand that. The other issue
> that comes up is time zones.  We've had this in the Nomcom and I found out
> recently that telecons at odd hours is the norm if you work in some
> SDOs.  I think these should be non-issues really.
>
> Perhaps the IESG job description should say in part, "you are expected to
> work some 35-40 hours a week on IESG stuff, should keep your calendar open
> in the months of ... for a retreat, and should be able to participate in
> telecons at odd hours." If you remove IESG from that sentence, it probably
> is already in many IETFers' job descriptions.

I think you have a reasonable understanding of the amount of time
involved and issues with time zones.

I think we should step away a bit from the word full time for the IESG
job. We recently discussed this in the IESG and it was felt my most of
us that a time commitment of at least 30 hours per week is needed,
while many ADs spend more than that. Whether people than find even
more time to do additional work is not really our problem as long it
doesn't affect IESG performance.

Many of our scheduling problems are related to timezones as you
already guessed: in practice we have a 8am-11am window (Pacific Time
Zone) that we can use for calls in the morning (from my perspective
and assuming that I am not traveling ;-)).

I have a bi-weekly 7-9 PT standards telecon and my colleagues would like me at the office before we dial-in to the conf calls. I am not a morning person, but so far I was able to make to those meetings, but time will tell.

I thought about this while nomcom telecons were going on. Perhaps a rotating schedule which makes it convenient in various time zones might help (for instance if someone in PT -- or worse some TZs in Asia -- volunteers for IESG, they don't have to tell themselves that they have to wakeup early for 2, 4 or 6 years!) The rotation may result in people missing meetings when there is a change, but it is probably worth a try. A weighted fair timezone scheduling algorithm is a good research topic for someone with a lot of free time :-).


Other issues are our different expertises: eg. I am the OPS AD and
feel that it is quite important to show up at various fora where
operational people show up like NANOG, Apricot and RIPE. I bet that
the Security Area Directors have their own security conferences etc.
that they feel that are important to attend. In addition, despite the
fact that many of us spend most of our time on the AD job, many of us
occasionally have a need to show up at our company headquarters.

Ok, I managed to forget this when I wrote my previous message. (I have seen some ADs at other meetings I go to, so I shouldn't have).

I guess I see it better now, but still think this is not an IETF-only problem and other people are making it work and so we should be able to as well. Do you guys share each others' calendars? That seems to help here at work. Someone has override authority to schedule meetings that need a large number of people with similar conflicts as above to attend.

best,
Lakshminath


Other issues include things like if you need to schedule something
with X people also X people need to respond and progress on finding a
common time is only as fast as the last person who reacts. And the
larger the group, the more likely this last person is quite late due
to various reasons from vacations, illness or to just being extra busy
during business travel.

Basically, trying to coordinate times that we can all be available is
often already challenging and results in scheduling meetings further
in the future than we would like to.

Note that is just one of the issues, there are many issues that occur
in the dynamics of a large group, whether is scheduling or simple
things like finding a problem on a conference call bridge where one
line causes a lot of noise which clearly takes a lot more time to
debug when the group is larger. And all these issues together are
decreasing our overall efficiency up to a point where things get
extremely hard to get any work done (see Harald's mail for a nice
explanation).

David Kessens
---


_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]