OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

openc2 message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [openc2] A motion to table the 'Meeting Times' motion


Trey,

Agreed, Let's adopt a convention of 13:00 Eastern and leave the actual 
implementation and scheduling to the discretion of the chairs.    I especially 
like your comment that we adopt a more collegial tone.  When we are working 
matters within the TC, it is to no one's advantage to habitually propose 
formal motions and potentially lead to a lot of procedural discourse.  Let's 
stay informal and agile when we can, and adopt formality when we really need 
to...

All,

Can we consider this matter closed?

VR

Joe B

-----Original Message-----
From: Trey Darley [mailto:trey@newcontext.com]
Sent: Wednesday, July 12, 2017 8:42 AM
To: Brule, Joseph M <jmbrule@radium.ncsc.mil>
Cc: 'White, Charles' <chuck@fornetix.com>; openc2@lists.oasis-open.org
Subject: Re: [openc2] A motion to table the 'Meeting Times' motion

On 12.07.2017 12:19:49, Brule, Joseph M wrote:
>
> To formally codify this as a standing rule, bylaw or whatever is
> another matter and is detrimental.
>

Hey, Joe -

I don't think anybody actually wants to carve 13h EDT in stone. That doesn't 
make sense for all the reasons you enumerated. I doubt whether
*any* OASIS TC has formalized their call schedule to that extent; certainly 
the CTI TC hasn't.

Somehow this conversation escalated from, "Hey, 11h EDT is a problem for the 
CTI TC and we've got a lot of folks active in both TCs. Could we please shift 
the regular calls to 13h?" to people making formal motions out of apparent 
frustration.

I'm not sure how we got here but I *do* know that this is detrimental to 
building a thriving community within the OpenC2 TC. Can we all please hit 
reset on this whole conversation and shift back to a more collegial tone?

>
> There is another consideration, albeit less vicarious. It appears that
> this 13:00 eastern time was selected as a matter of convenience for
> members of a particular TC and I suspect that this time is not going
> to be particularly good for our European colleagues. Do we REALLY want
> to create the perception that the OpenC2 TC operates at the
> convenience of a subset of the American members to the point where we
> micromanage how the SC, tiger team and study groups schedule their
> meetings?
>

As both a CTI TC co-chair *and* a European colleague, I confront this issue 
every week, so I really appreciate your empathy in raising the point, Joe.

Scheduling calls that work for everybody is impossible. EMEA is one thing, but 
don't forget about APAC. Over in the CTI TC we've long been running an 
alternate monthly TC call at a time more convenient for APAC (so folks don't 
have to get up at 04h just to maintain their TC voting rights).

Apart from this, it's catch-as-catch-can. I'm frequently on CTI TC calls 
running late into my night and there are a number of folks I know in APAC who 
wrest themselves out of bed at insane hours to join working calls. It's just 
the nature of the beast.

Asynchronous channels like Slack and email enable folks unable to join working 
calls to meaningfully participate in development work. It's
*not* the same as being on a working call, but it's the best we've been able 
to come up with.

--
Cheers,
Trey
++--------------------------------------------------------------------------++
Director of Standards Development, New Context gpg fingerprint: 3918 9D7E 50F5 
088F 823F  018A 831A 270A 6C4F C338
++--------------------------------------------------------------------------++
--
"It is in the admission of ignorance and the admission of uncertainty that 
there is a hope for the continuous motion of human beings in some direction 
that doesn't get confined, permanently blocked, as it has so many times before 
in various periods in the history of man." --Richard Feynman

Attachment: smime.p7s
Description: S/MIME cryptographic signature



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]