Document limitations and requirements around using chat tools like Slack #22

OASIS-OP-Admin · 2024-01-26T18:30:12Z

Jason has reminded me that we do not have policy documented for use of Slack, Skype or other chat tools by projects. Currently, tools like Slack violate our transparency requirements: non-members have to ask to be added before they can see the discussion; there is no way to link to an entry so that someone outside can read the exchange; there's no archival record of the conversation; and there is no way to limit participation to members of the project.

Proj Admin has handled this historically by telling projects that Slack, etc., are not approved OASIS platforms and that any exchanges that take place have no more standing that a hallway conversation. No work can be done there. Specifically, no contributions can be made there, no approvals can happen there, and it is up to the members to police its use. Note that the verb here is "tell."

We don't suggest telling projects that they can't use these tools because they are too convenient and they can easily go off and do them on their own anyway.

So we think it would make sense to put the policy into writing. That ensures that the board has given it consideration and also ensures that we tell everybody the same story every time.

While this could be done as tweaks to the TC Process and OP Rules, it may be better - since something new will certainly come along - to draft it as its own policy.

jordan2175 · 2024-01-27T04:30:56Z

I agree that we should work on a policy document. But I want to push back on some wrongful assumptions.

We are no longer in the 1990s. People do not use email or list-srv email lists to discuss things. Nor do they use email based threaded discussion boards. Those were fantastic back in 1994.
You can easily lock down Slack to only allow members. We did that in the CTI TC and in the CACAO TC and in the OpenC2 TC. It is not hard at all. And those TCs are the largest TCs OASIS has ever had.
Saying you can not do business over Slack or things like it, is like saying you can not have a direct email conversation, or phone call, or even a web call to discuss things. Keep in mind that TC meetings over zoom or webex or Gotomeeting or Meet do business all of the time and most of that is never recorded in a way that public people can come back and review. If, and I mean IF there are meeting minutes they are usually so sparse and un-useful that someone would never be able to go back and figure out how or why something was done. There is no email thread to follow all of the discussions, because it is not the 1990s anymore.
Sometimes all of the voting members are in slack and are participating in every discussion. So in these cases it is better than a TC Meeting that is over zoom where you may only get half of the voting members.

Now with all of that said, we should write some documentations to help TCs do better at documenting decisions. And if a decision is made by the majority of voting members that are participating in a slack conversation, then maybe they should send an email at the end of the week that just documents the various things. What CTI and CACAO have done is try to send a note to the email list saying the following was talked about or the following changes decisions have been made?

What I have seem some groups in other standards bodies do, which I kind of like (though it is a lot more work). Is they have a separate document open that documents changes and decisions on a section by section basis. But that runs into problems especially in the early days when document structures can change a lot and very significantly. As section 2.1 may be come section 4.4 and then 7.1 and then 1.3 and then back to 2.8.

This is somewhat tangential to this conversation but deals with the preceding paragraph. This is why I think OASIS should adopt a model where work is done by contributions. Especially for new work items. Like there should be authors of a contribution that come to the TC with something that is somewhat fleshed out and it only becomes a CSD once it is a tangible thing.

chet-ensign · 2024-01-30T17:47:54Z

Bret, I'm adding the process committee email to make sure this gets full visibility. I add some comments below but my main point is that we need to consider this and put guidance in writing. Different groups are getting different messages right now and that's not good.

On Fri, Jan 26, 2024 at 11:31 PM Bret Jordan ***@***.***> wrote: I agree that we should work on a policy document. But I want to push back on some wrongful assumptions. 1. We are no longer in the 1990s. People do not use email or list-srv email lists to discuss things. Nor do they use email based threaded discussion boards. Those were fantastic back in 1994. 2. You can easily lock down Slack to only allow members. I meant control access automatically from the roster. The only way I know

of to control access is for the chair or someone to manually check the subscribers from time to time and remove those who have left the TC. I am confident that few Slack channels are rigorously maintained and many probably let anybody in who asks whether members of the TC or not.

1. We did that in the CTI TC and in the CACAO TC and in the OpenC2 TC. It is not hard at all. And those TCs are the largest TCs OASIS has ever had. 2. Saying you can not do business over Slack or things like it, is like saying you can not have a direct email conversation I should be more clear about what I mean by business. And this makes me

think we have an even bigger question before us, namely, what actions or transactions must take place or be recorded in a public way in order for us to be able to say that a standard was developed in an open way and provide interested parties with directions to the critical events. Have what I would consider OASIS fundamentals changed? I think that by "business" I mean contributions and OASIS standards deliverables approvals. Those I think are fundamentals that haven't really happened until they've happened on the public record. So, for example, somebody could share some code on Slack and people could talk about it there, but it isn't yet a contribution under our rules. It is a contribution when the person who owns it takes it and puts it on the TC mailing list or -comment@ list. Likewise approvals; all the voting members can be on Slack and give a thumbs up that something can become a Committee Specification but that isn't approval. The approval of the CS has to happen in the open on the TC's official platform. CSD approvals? OK. Probably not mission critical if they're done with thumbs up/down icons. And conversation, discussion, brainstorming, like you say - equivalent to chatting in a hall or over lunch. But Contributions and Approvals can't be done on a chat platform.

1. , or phone call, or even a web call to discuss things. Keep in mind that TC meetings over zoom or webex or Gotomeeting or Meet do business all of the time and most of that is never recorded in a way that public people can come back and review. If, and I mean IF there are meeting minutes they are usually so sparse and un-useful Yes, minutes is a whole nother can of worms. 1. that someone would never be able to go back and figure out how or why something was done. There is no email thread to follow all of the discussions, because it is not the 1990s anymore. 2. Sometimes all of the voting members are in slack and are participating in every discussion. So in these cases it is better than a TC Meeting that is over zoom where you may only get half of the voting members. Now with all of that said, we should write some documentations to help TCs do better at documenting decisions.

I agree. At the very least, give some guidance they can follow if they care.

And if a decision is made by the majority of voting members that are participating in a slack conversation, then maybe they should send an email at the end of the week that just documents the various things. What CTI and CACAO have done is try to send a note to the email list saying the following was talked about or the following changes decisions have been made? What I have seem some groups in other standards bodies do, which I kind of like (though it is a lot more work). Is they have a separate document open that documents changes and decisions on a section by section basis. But that runs into problems especially in the early days when document structures can change a lot and very significantly. As section 2.1 may be come section 4.4 and then 7.1 and then 1.3 and then back to 2.8. This is somewhat tangential to this conversation but deals with the preceding paragraph. This is why I think OASIS should adopt a model where work is done by contributions. Especially for new work items. Like there should be authors of a contribution that come to the TC with something that is somewhat fleshed out and it only becomes a CSD once it is a tangible thing.

To me, the question is now turning into 2 topics: (a) what are the events that *must* be done on the access-controlled, publicly visible platform? (b) what are best practices for documenting progress on the interim work products in a way that doesn't impose a burden on the members and that encourages engagement and adoption of the standards broadly? We've maybe got a runway here to make things smoother and use popular, emerging tech to the good of the organization.

…

— Reply to this email directly, view it on GitHub <#22 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACYUWRL6KF4WKNFXF4E4ZTTYQR7IXAVCNFSM6AAAAABCMRVWSGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJSHE4DCMJZGE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.*** com>

-- Chet Ensign Chief Technical Community Steward OASIS Open +1 201-341-1393 <+1+201-341-1393> ***@***.*** www.oasis-open.org

jordan2175 · 2024-01-30T20:41:16Z

But we can do business in a live meeting of the TC that is not open to the public and is not recorded on the email list. We can do a live vote or call for consent in a meeting of the TC. Meetings of the TC can take place via ANY technology platform so long as they are published to the TC or the TC knows about them. So yes, we need to make sure we talk about this. But it is not a simple fix either way. Bret Sent from my TI-99/4A PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 On Tue, Jan 30, 2024 at 9:48 AM Chet Ensign ***@***.***> wrote:

…

Bret, I'm adding the process committee email to make sure this gets full visibility. I add some comments below but my main point is that we need to consider this and put guidance in writing. Different groups are getting different messages right now and that's not good. On Fri, Jan 26, 2024 at 11:31 PM Bret Jordan ***@***.***> wrote: > I agree that we should work on a policy document. But I want to push back > on some wrongful assumptions. > > 1. We are no longer in the 1990s. People do not use email or list-srv > email lists to discuss things. Nor do they use email based threaded > discussion boards. Those were fantastic back in 1994. > 2. You can easily lock down Slack to only allow members. > > I meant control access automatically from the roster. The only way I know of to control access is for the chair or someone to manually check the subscribers from time to time and remove those who have left the TC. I am confident that few Slack channels are rigorously maintained and many probably let anybody in who asks whether members of the TC or not. > > 1. We did that in the CTI TC and in the CACAO TC and in the OpenC2 TC. > It is not hard at all. And those TCs are the largest TCs OASIS has ever had. > 2. Saying you can not do business over Slack or things like it, is > like saying you can not have a direct email conversation > > I should be more clear about what I mean by business. And this makes me think we have an even bigger question before us, namely, what actions or transactions must take place or be recorded in a public way in order for us to be able to say that a standard was developed in an open way and provide interested parties with directions to the critical events. Have what I would consider OASIS fundamentals changed? I think that by "business" I mean contributions and OASIS standards deliverables approvals. Those I think are fundamentals that haven't really happened until they've happened on the public record. So, for example, somebody could share some code on Slack and people could talk about it there, but it isn't yet a contribution under our rules. It is a contribution when the person who owns it takes it and puts it on the TC mailing list or -comment@ list. Likewise approvals; all the voting members can be on Slack and give a thumbs up that something can become a Committee Specification but that isn't approval. The approval of the CS has to happen in the open on the TC's official platform. CSD approvals? OK. Probably not mission critical if they're done with thumbs up/down icons. And conversation, discussion, brainstorming, like you say - equivalent to chatting in a hall or over lunch. But Contributions and Approvals can't be done on a chat platform. > > 1. , or phone call, or even a web call to discuss things. Keep in mind > that TC meetings over zoom or webex or Gotomeeting or Meet do business all > of the time and most of that is never recorded in a way that public people > can come back and review. If, and I mean IF there are meeting minutes they > are usually so sparse and un-useful > > Yes, minutes is a whole nother can of worms. > > 1. that someone would never be able to go back and figure out how or > why something was done. There is no email thread to follow all of the > discussions, because it is not the 1990s anymore. > 2. Sometimes all of the voting members are in slack and are > participating in every discussion. So in these cases it is better than a TC > Meeting that is over zoom where you may only get half of the voting members. > > Now with all of that said, we should write some documentations to help TCs > do better at documenting decisions. > I agree. At the very least, give some guidance they can follow if they care. > And if a decision is made by the majority of voting members that are > participating in a slack conversation, then maybe they should send an email > at the end of the week that just documents the various things. What CTI and > CACAO have done is try to send a note to the email list saying the > following was talked about or the following changes decisions have been > made? > > What I have seem some groups in other standards bodies do, which I kind of > like (though it is a lot more work). Is they have a separate document open > that documents changes and decisions on a section by section basis. But > that runs into problems especially in the early days when document > structures can change a lot and very significantly. As section 2.1 may be > come section 4.4 and then 7.1 and then 1.3 and then back to 2.8. > > This is somewhat tangential to this conversation but deals with the > preceding paragraph. This is why I think OASIS should adopt a model where > work is done by contributions. Especially for new work items. Like there > should be authors of a contribution that come to the TC with something that > is somewhat fleshed out and it only becomes a CSD once it is a tangible > thing. > To me, the question is now turning into 2 topics: (a) what are the events that *must* be done on the access-controlled, publicly visible platform? (b) what are best practices for documenting progress on the interim work products in a way that doesn't impose a burden on the members and that encourages engagement and adoption of the standards broadly? We've maybe got a runway here to make things smoother and use popular, emerging tech to the good of the organization. > — > Reply to this email directly, view it on GitHub > < #22 (comment)>, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/ACYUWRL6KF4WKNFXF4E4ZTTYQR7IXAVCNFSM6AAAAABCMRVWSGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJSHE4DCMJZGE> > . > You are receiving this because you are subscribed to this thread.Message > ID: ***@***.*** > com> > -- Chet Ensign Chief Technical Community Steward OASIS Open +1 201-341-1393 <+1+201-341-1393> ***@***.*** www.oasis-open.org — Reply to this email directly, view it on GitHub <#22 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACMTMGCYN4FXVKX7UQ4IVSDYREW5LAVCNFSM6AAAAABCMRVWSGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJXGU3TMNBQG4> . You are receiving this because you commented.Message ID: ***@***.***>

sparrell · 2024-01-30T20:41:17Z

I want to push back on “People do not use email or list-srv email lists to discuss things.” Some people do. Not everyone does. All people probably could. Im fine with having a messaging policy - But I would like email to still be a choice. iPhone, iTypo, iApologize

________________________________ From: Chet Ensign ***@***.***> Sent: Tuesday, January 30, 2024 7:48:06 AM To: oasis-board-process-committee/TC-Process ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [oasis-board-process-committee/TC-Process] Document limitations and requirements around using chat tools like Slack (Issue #22) Bret, I'm adding the process committee email to make sure this gets full visibility. I add some comments below but my main point is that we need to consider this and put guidance in writing. Different groups are getting different messages right now and that's not good.