|I would echo these points:|
1) the groups will be producing proposals that will then come back to the list and regular working phone calls for everyone to contribute, give feedback, and discuss. They are not deciding on anything.
2) this idea of getting people together and coming up with a proposal has been done in this community all along. In the past people just used Skype chats, IM, direct emails, f2f conference rooms, and phone calls.
3) There are some people that do not like slack or can not use slack. There are also people that complain about the volume of email on the list. To be clear, since we started using slack, there has been 34.4K messages send on slack. If we do not use slack, then all of that content will flow over to email. Do you really want 34.4K more email messages?
What we have tried to do, to date, is recap discussions that we have had on slack on our weekly/monthly phone calls for those that can not or choose to not participate. As proposals get fleshed out, we then copy that normative text in to the Google Docs so everyone can comments, discuss, or otherwise provide feedback.
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO
Blue Coat Systems
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg."
FWIW, the co-chairs have socialized the usage of slack, slack’s limitations, and potential solutions (i.e., Jason’s logger) with the right folks at OASIS. We did this early on when we started using slack. To date we haven’t heard any requests to change
what we are doing so we haven’t. If this changes in the future we’ll adapt as necessary.
I do hope that we keep slack – otherwise, all this traffic will end up getting dumped onto the email lists (screen cap from Slack stats page):
I want to reiterate what Sean said: the intent is that these working groups will be bringing back their results to the full list (and via the phone calls) for discussion. Nothing is being decided in the working groups, they’re spending intense effort to
come to proposals that the entire list gets to review.
Additionally though we do move fairly quickly, we’re also (unlike for STIX 1.x) going to be developing prototypes and working software against these processes/models before they get formalized. I think overall that will give us a data model that is better
vetted against the real world and more understood than what we had with STIX 1.x, which was essentially just us writing stuff that we thought worked in theory and hoping that it would work in practice (case in point: data markings).
I do hear the concern with Slack being blocked and I’m hoping that we can figure out some way of leveraging Jason’s code to get them auto posted on a daily basis. More importantly, I know many of the working groups are scheduling calls: given that not
everyone monitors slack yet might participate in a call, all of those calls should be posted to the mailing list so people who aren’t on Slack know they’re occurring.
IMO the rules for working groups should be:
- Each full week, send a post to the list with a summary of progress. Once a week is not insane
- If you schedule any discussions, send them to the list
- If team members can’t use slack, try to work around it (have more calls, work with them daily over e-mail, etc)
I have similar concerns.
I think we should move as rapidly as we can while still making deliberate decisions based on a full understanding of each situation. We should never let arbitrary or artificial timelines force us to make hasty or poorly informed decisions. I have no objections
to working groups focused on specific tasks as long as they are inclusive of anyone wishing to collaborate and express input, as long as they actively seek to fully understand the task at focus and not to artificially constrain its scope to anyone’s personal
preferences and as long as it is clear that the results from any working group are only a headstart to work from and not a settled solution. We need to be careful to present the results of a working group to the TC for ongoing discussion in a way that does
not put the onus on TC members not in the working group to somehow have to “justify” their dissenting opinions. All opinions should be treated equally and with respect.
If we can do working groups in this way, I believe they can be a successful approach.
I also understand and concur with your concerns on the Slack issue.
I think we need to talk through and find a solution to these concerns.
I believe that these efforts to make quick changes risks making hasty changes that are not adequately considered and that we will later regret.
Furthermore, these mini-working groups break the transparency that was expected when moving to OASIS. Frankly, I am surprised that OASIS is permitting the use of Slack - how do those discussion get tracked within OASIS systems? Currently, my organization
does not permit access to Slack so we do not have a way to see those discussion, never mind contribute.
Until these questions are resolved, I recommend against these mini-working groups or further breakout discussions on Slack.
Sent: Thursday, March 10, 2016 11:14 PM
Subject: [Non-DoD Source] [cti] New Mini-Working Groups
We have kicked off a few mini-working groups to address some key issues, they are as follows:
1) Patterning: Allan, John-Mark, Jason, and Ivan are heading up this discussion. Anyone can join in on Slack at #patterning or on email. The due date for this proposal is Tuesday March 22nd.
2) Versioning: Looking for 3-4 people to lead this work. Anyone can join in on Slack at #versioning or on email. The due date for this proposal is Tuesday March 22nd
3) Sightings: Looking for 3-4 people to lead this work. Anyone can join on Slack at #sightings or on email. This due date for this proposal is Tuesday March 22nd.
In general we will try and run 3-4 mini-working groups at a time, each with a 2 week delivery window. You can think of it as a sprint in development terms. If you want to be involved early on in the proposal phase, PLEASE make it known.
Further, we hope to get leadership setup for Versioning and Sightings tomorrow. If any of you are interested in helping to lead either one of these, please let us know. (btw, we are looking for 3-4 leaders for each topic). They will be responsible for
driving the discussion, gathering feedback from everyone, writing up proposed normative text, and then presenting their proposal on a CTI wide working call.
Bret Jordan CISSP
Director of Security Architecture and Standards | Office of the CTO Blue Coat Systems PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at: