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: Communication channels


I disagree with Bret’s opinion below that we restrict which communication mechanisms we use. I’m fine with discussion taking place in several places. Different mechanisms are better for different purposes. I’d rather not restrict communication and I do support experimentation.

I do think maybe we could make some guidelines for which goes where to make it easier and to play to each channels strengths and to make it easier to find stuff. For example any given topic (eg the organization topic that started this chainmail) should say something like:
- try to use slack for ‘real time’-ish discussion of a temporary nature (ie record results elsewhere once they are reached)
- try to use email to alert people to meeting or particular points more viewpoints are needed on. Use sparingly. If you are back&frothing with someone - use slack.
- try to use google docs for a draft position and comments on it. See (link here)
- try to use wiki (link here) to record apparent agreements, send email alerting everyone to existence of wiki page asking for concurrence or comment. 
This is an example to show idea- not a proposal for this specific case. My point is a different topic could have a different set and all of these are ‘try’ - we don’t exclude anyone from using any channel. I’d rather have participation than cut anyone off. For example, Slack and google docs are great but not all corporations allow access to them. We shouldn’t cut off the majority if a few can’t use, and we shouldn’t exclude the few using alternative methods.

Btw I’d replace Bret’s 4 &5 with the other three real mechanisms we have at our disposal and don’t use as much as I’d like:
1) OASIS working documents - Anyone can submit a document stating their position. Alan used this well with his comments on Language CSD. Most other standards bodies I’ve worked in over the last 37 years only allow this mechanism. I agree we should allow the others but we should make better use of ‘contributions’ - particularly for long nuanced commentary stating positions, your arguments, and your counter arguments to others. This email should have been a contribution!
2) OASIS wiki - I like wiki’s. Obviously some other members don’t. I don’t think they are good for give and take and ‘discussion’. I do think they are good for recording status and agreements. They are like #1 when you want something written collaboratively.
3) github (for text) and github issues (for issues) - Github is designed for collaborative text (aka source code) creation and editing with really good change management. Github has 3.5 million users ad 6.8 million repositories so it must be useful for something
4) discourse - Sounil has reported Bank of America has had success using this for collaborative resolving of issues. I think we should add to our toolkit. Sounil has set up an instance the cochairs have started to play with I think it should be extended.

But to reiterate my main point - I don’t think we are mature enough yet to be restricting communication channels.

Duncan

iPhone, iTypo, iApologize

Duncan Sparrell
sFractal Consulting, LLC
The closer you look, the more you see
_____________________________
From: Bret Jordan <bret_jordan@symantec.com>
Sent: Thursday, November 16, 2017 8:24 PM
Subject: Re: [EXT] RE: presentation for TC meeting next week
To: Brule, Joseph M <jmbrule@radium.ncsc.mil>, Kemp, David P <dpkemp@radium.ncsc.mil>, 'Fai, Joyce' <joyce.fai@gd-ms.com>, Allan Thomson <athomson@lookingglasscyber.com>, dave.lemire <dave.lemire@g2-inc.com>
Cc: Jyoti Verma (jyoverma) <jyoverma@cisco.com>, Trey Darley <trey@newcontext.com>, <duncan@sfractal.com>, Yu, Sounil <sounil.yu@bankofamerica.com>


For the love of all things holy, can we please have the discussion ONLY in one place.  We as a TC are failing all over the place here.  We need to pick:

1) email,

2) slack

3) google docs

4) carrier pigeons

5) Deepspace array


I do not care.  But we need ONE place people can go to, to find things. Having content spread everywhere makes it near impossible for people to figure out what is going on.  We are basically saying, that unless you are super active in every piece of dialog, you will have NO IDEA what is really going on.


I love slack and google docs, but I am beginning to really think that we should just do everything over email.  


Bret


From: Brule, Joseph M <jmbrule@radium.ncsc.mil>
Sent: Thursday, November 16, 2017 9:56:14 AM
To: Kemp, David P; 'Fai, Joyce'; Allan Thomson; dave.lemire
Cc: Jyoti Verma (jyoverma); Bret Jordan; Trey Darley; duncan@sfractal.com; Yu, Sounil; Jyoti Verma (jyoverma)
Subject: [EXT] RE: presentation for TC meeting next week
 

Jason R already cooked up a slack channel, but I think the googledoc is a good idea too.

 

From: Kemp, David P
Sent: Thursday, November 16, 2017 11:02 AM
To: Brule, Joseph M <jmbrule@radium.ncsc.mil>; 'Fai, Joyce' <Joyce.Fai@gd-ms.com>; Allan Thomson <athomson@lookingglasscyber.com>; dave.lemire <dave.lemire@g2-inc.com>
Cc: Jyoti Verma (jyoverma) <jyoverma@cisco.com>; Bret Jordan (CS) <bret_jordan@symantec.com>; Trey Darley <trey@newcontext.com>; duncan@sfractal.com; Yu, Sounil <sounil.yu@bankofamerica.com>; Jyoti Verma (jyoverma) <jyoverma@cisco.com>; Kemp, David P <dpkemp@radium.ncsc.mil>
Subject: RE: presentation for TC meeting next week

 

Joe Brule: Author

Joyce Fai: Editor

Dave Lemire: Reasonable

Allan Thomson: +1

Dave Kemp:  +1

 

Since all who have responded support having an electronic discussion followed by an electronic ballot, I don’t believe a TC vote is needed to put the process into motionJ.   We are using a google doc in the TC playground folder to discuss targets; that seems to be a reasonable approach for this topic, but other media would work too.

 

Any objections to starting the discussion?

 

Dave

 

P.S.,

I believe that if there are a certain number of topics or amount of material a person wants to cover, a specific amount of time is required to cover them regardless of where that time is spent.  The goal of the TC/SC structure is to avoid wasting anyone’s time, allowing the available time to be spent most efficiently.   Duncan’s approach – each group “sticks to it’s knitting” – is the most efficient.  Assigning one topic to more than one group reduces efficiency.  Assigning too many topics to one group also reduces efficiency.

 

If a student needs to study math, history, literature, and phys-ed, putting history and math into the same class does not reduce the amount of time needed to learn both topics, and it wastes the time of students who need to learn history but not math.  If a vendor needs to cover message encryption and target formats, putting those topics in the same subcommittee doesn’t reduce the amount of time needed to cover them, and it wastes the time of people who want to focus on one but only maintain awareness of the other.

 

Merging subcommittees wastes people’s time, and deliberating a single topic in multiple subcommittees also wastes people’s time.  So I am not in favor of doing either.

 

 

 





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