Topics

Collaboration Tools

Sean Cooper
 

Hello,

I'm on the development team for OpenColorIO, and would like to raise the conversation around project communication platforms. Quickly looking at the Collaboration Tools list for ASWF I see the usual options of Mailing Lists and Issue Tracking. However, OCIO has greatly benefited by having real-time communication through a Slack group which promotes candid responses from maintainers and community members instead of long essays like this. I believe this fosters a greater feeling of participation and community which was very helpful in re-kindling development with the project.

I'm am definitely not a proponent of Slack. In fact, I really dislike it and am starting the conversation with our community on switching to an alternative. When/if OpenColorIO is moved under the care of the ASWF, I would like to see a real-time communication platform promoted. At the moment the best option which I have yet to use in practice is Zulip (https://zulipchat.com/for/open-source/).

The features they offer seem to be a substantial gain over Slack or alternatives.
  • Apache 2.0 Licensed
  • Free hosting for OSS (maybe ASWF hosts a server)
  • Join without invitation
  • Permalink to conversations
  • Github issue links e.g. #1234
  • Github/Jenkins/TravisCI integrations
  • Proper nested conversations (thank goodness)
  • Public archival coming soon apparently
In summary, real-time communication with asynchronous participation is vital to project success. With the declining use of email-lists ( https://arxiv.org/pdf/1803.09529.pdf) I'd love to see an option promoted and used across ASWF projects.

Thanh Ha
 

On Wed, Aug 22, 2018 at 9:01 AM <sean@...> wrote:
Hello,

I'm on the development team for OpenColorIO, and would like to raise the conversation around project communication platforms. Quickly looking at the Collaboration Tools list for ASWF I see the usual options of Mailing Lists and Issue Tracking. However, OCIO has greatly benefited by having real-time communication through a Slack group which promotes candid responses from maintainers and community members instead of long essays like this. I believe this fosters a greater feeling of participation and community which was very helpful in re-kindling development with the project.

I'm am definitely not a proponent of Slack. In fact, I really dislike it and am starting the conversation with our community on switching to an alternative. When/if OpenColorIO is moved under the care of the ASWF, I would like to see a real-time communication platform promoted. At the moment the best option which I have yet to use in practice is Zulip (https://zulipchat.com/for/open-source/).

The features they offer seem to be a substantial gain over Slack or alternatives.
  • Apache 2.0 Licensed
  • Free hosting for OSS (maybe ASWF hosts a server)
  • Join without invitation
  • Permalink to conversations
  • Github issue links e.g. #1234
  • Github/Jenkins/TravisCI integrations
  • Proper nested conversations (thank goodness)
  • Public archival coming soon apparently
In summary, real-time communication with asynchronous participation is vital to project success. With the declining use of email-lists ( https://arxiv.org/pdf/1803.09529.pdf) I'd love to see an option promoted and used across ASWF projects.

Many Open Source projects use Freenode IRC. Something that I think a lot of these new tools miss is that there's no single agreed upon server for Open Source projects in general, so if folks want to cross collaborate with another community it's harder (need new accounts on different systems just to join 1 channel).

If you work with 10 different project communities and have to connect to 10 different tools / protocols it quickly get's out of hand. I'm not sure if anyone else participates in multiple project communities but if ASWF plans to cross collaborate with another community (maybe dependency projects) it is much easier to just "/join #channel" then to have to sign up for an entirely new account on another system.

Something ASWF might want to consider when choosing a collaboration tool.

Regards,
Thanh

Scott Petrovic
 

I would agree that real-time chat is extremely important with any type of project. We use it on a daily basis when we are hashing out ideas, having meetings, or trying to solve problems. We still use the old school IRC, but we also have an IRC web client for non-technical people (https://krita.org/en/irc/) . The main reason we have stayed with IRC is that you don't have to have an account to talk with people. This is great from a support standpoint with people just wanting to ask a question, but that concern might not be relevant with this group.

I am not sure if this is a concern for the ASWF, but having a public archive might be something you may, or may not want for the realtime chat. If the entire history of conversations are preserved, that can sometimes lead to privacy issues where people don't want everything they say "on the record". Not everything is always well thought out when you can talk in real time. Lists like this people at least have a bit of time to reflect on something before they post it.

Edward Warnicke
 

Sean,

Community personalities differ, and its important to find the tool that fits them.

I’ve worked in communities that *only* operate via mailing lists, you can’t get *anyone* on slack or IRC.
I’ve also worked in communities where almost *everything* happens on slack and IRC and the mailing lists are moribund.

Slack and IRC each have their pluses and minuses.  Choosing one is something that the ASWF community is going to have to do for itself.

You also need to decide whether to have a single ASWF slack with channels for the projects, or a slack channel per project.
Again, the appropriate choice is going to be dictated by the particular personalities of the projects in ASWF.

My recommendation would be to make a quick ‘starter call’ and get something going, and then see how it goes.  Some things simply require experimentation.

Ed

On August 22, 2018 at 9:45:55 AM, Thanh Ha (thanh.ha@...) wrote:

On Wed, Aug 22, 2018 at 9:01 AM <sean@...> wrote:
Hello,

I'm on the development team for OpenColorIO, and would like to raise the conversation around project communication platforms. Quickly looking at the Collaboration Tools list for ASWF I see the usual options of Mailing Lists and Issue Tracking. However, OCIO has greatly benefited by having real-time communication through a Slack group which promotes candid responses from maintainers and community members instead of long essays like this. I believe this fosters a greater feeling of participation and community which was very helpful in re-kindling development with the project.

I'm am definitely not a proponent of Slack. In fact, I really dislike it and am starting the conversation with our community on switching to an alternative. When/if OpenColorIO is moved under the care of the ASWF, I would like to see a real-time communication platform promoted. At the moment the best option which I have yet to use in practice is Zulip (https://zulipchat.com/for/open-source/).

The features they offer seem to be a substantial gain over Slack or alternatives.
  • Apache 2.0 Licensed
  • Free hosting for OSS (maybe ASWF hosts a server)
  • Join without invitation
  • Permalink to conversations
  • Github issue links e.g. #1234
  • Github/Jenkins/TravisCI integrations
  • Proper nested conversations (thank goodness)
  • Public archival coming soon apparently
In summary, real-time communication with asynchronous participation is vital to project success. With the declining use of email-lists ( https://arxiv.org/pdf/1803.09529.pdf) I'd love to see an option promoted and used across ASWF projects.

Many Open Source projects use Freenode IRC. Something that I think a lot of these new tools miss is that there's no single agreed upon server for Open Source projects in general, so if folks want to cross collaborate with another community it's harder (need new accounts on different systems just to join 1 channel).

If you work with 10 different project communities and have to connect to 10 different tools / protocols it quickly get's out of hand. I'm not sure if anyone else participates in multiple project communities but if ASWF plans to cross collaborate with another community (maybe dependency projects) it is much easier to just "/join #channel" then to have to sign up for an entirely new account on another system.

Something ASWF might want to consider when choosing a collaboration tool.

Regards,
Thanh

Sean Cooper
 

Thanks,

Yes, I don't want my comment to seem to impose my solution, but exactly to the point above if something isn't chosen at the get-go, each sub-project will do their own thing and some uniformity would be great.

Each project has different communities and different paces of development of course, so I don't think its right to force anyone to use a real-time tool if Email Lists get the job done, but having one answer when people start asking for it would be nice and ease integration and cross-project communication.

Perhaps I'm just a young yuppie, but abandoning modern features for IRC could work but logging would be a must, and from following ffmpeg development even loosely finding any conversation is horrible unless you know the exact day and time the conversation happened, and you better hope no one else asked a question in between. This is why I'm so drawn to the Zulip real-time threads concept. I agree though, an option to join a channel without signing up would be great. I've asked that question to Zulip here if you care to follow.


On Wed, Aug 22, 2018 at 3:57 PM, Edward Warnicke <hagbard@...> wrote:
Sean,

Community personalities differ, and its important to find the tool that fits them.

I’ve worked in communities that *only* operate via mailing lists, you can’t get *anyone* on slack or IRC.
I’ve also worked in communities where almost *everything* happens on slack and IRC and the mailing lists are moribund.

Slack and IRC each have their pluses and minuses.  Choosing one is something that the ASWF community is going to have to do for itself.

You also need to decide whether to have a single ASWF slack with channels for the projects, or a slack channel per project.
Again, the appropriate choice is going to be dictated by the particular personalities of the projects in ASWF.

My recommendation would be to make a quick ‘starter call’ and get something going, and then see how it goes.  Some things simply require experimentation.

Ed

On August 22, 2018 at 9:45:55 AM, Thanh Ha (thanh.ha@...) wrote:

On Wed, Aug 22, 2018 at 9:01 AM <sean@...> wrote:
Hello,

I'm on the development team for OpenColorIO, and would like to raise the conversation around project communication platforms. Quickly looking at the Collaboration Tools list for ASWF I see the usual options of Mailing Lists and Issue Tracking. However, OCIO has greatly benefited by having real-time communication through a Slack group which promotes candid responses from maintainers and community members instead of long essays like this. I believe this fosters a greater feeling of participation and community which was very helpful in re-kindling development with the project.

I'm am definitely not a proponent of Slack. In fact, I really dislike it and am starting the conversation with our community on switching to an alternative. When/if OpenColorIO is moved under the care of the ASWF, I would like to see a real-time communication platform promoted. At the moment the best option which I have yet to use in practice is Zulip (https://zulipchat.com/for/open-source/).

The features they offer seem to be a substantial gain over Slack or alternatives.
  • Apache 2.0 Licensed
  • Free hosting for OSS (maybe ASWF hosts a server)
  • Join without invitation
  • Permalink to conversations
  • Github issue links e.g. #1234
  • Github/Jenkins/TravisCI integrations
  • Proper nested conversations (thank goodness)
  • Public archival coming soon apparently
In summary, real-time communication with asynchronous participation is vital to project success. With the declining use of email-lists ( https://arxiv.org/pdf/1803.09529.pdf) I'd love to see an option promoted and used across ASWF projects.

Many Open Source projects use Freenode IRC. Something that I think a lot of these new tools miss is that there's no single agreed upon server for Open Source projects in general, so if folks want to cross collaborate with another community it's harder (need new accounts on different systems just to join 1 channel).

If you work with 10 different project communities and have to connect to 10 different tools / protocols it quickly get's out of hand. I'm not sure if anyone else participates in multiple project communities but if ASWF plans to cross collaborate with another community (maybe dependency projects) it is much easier to just "/join #channel" then to have to sign up for an entirely new account on another system.

Something ASWF might want to consider when choosing a collaboration tool.

Regards,
Thanh


Jim Houston
 


On Aug 22, 2018, at 9:04 AM, Sean Cooper <sean@...> wrote:


I think you just proved that threading is a must :-)

I agree though, an option to join a channel without signing up would be great.

+1

A consistent approach among projects would be great.   I think it is difficult though to use a new startup’s tool
because they are still chasing a business model.  What features will still be present and/or advancing and which
go by the wayside.  

For a project started in 2004, I found it very useful at times to have the history of the project and 
sample images that were used still available.  It is a significant nuisance when past e-mail/posts point to dead links
because of a change in the collaboration tool.  This is true as well in SMPTE’s Kavi (higher logic) where reorganizations
have wiped clean previous threads.  Although working in the moment on current topics is important for collaboration,
I would also suggest the benefits of long-term learning from past decisions can be useful.

Especially in software projects where it seems that every decade or so, there is a significant throwing out of previous efforts
sometimes ignoring the benefits of tested and working codes.  (acknowledging that sometimes spaghetti just has to GO )

Jim Houston


Larry Gritz
 

Am I just a cranky old man for preferring mail lists and dreading using Slack or IRC? They're ok for totally ephemeral "gotta do this thing right now" stuff, but I hate when actual substantive discussions or decisions for projects are made on those channels.



On August 22, 2018 10:08:04 AM PDT, Jim Houston <jim.houston@...> wrote:

On Aug 22, 2018, at 9:04 AM, Sean Cooper <sean@...> wrote:


I think you just proved that threading is a must :-)

I agree though, an option to join a channel without signing up would be great.

+1

A consistent approach among projects would be great.   I think it is difficult though to use a new startup’s tool
because they are still chasing a business model.  What features will still be present and/or advancing and which
go by the wayside.  

For a project started in 2004, I found it very useful at times to have the history of the project and 
sample images that were used still available.  It is a significant nuisance when past e-mail/posts point to dead links
because of a change in the collaboration tool.  This is true as well in SMPTE’s Kavi (higher logic) where reorganizations
have wiped clean previous threads.  Although working in the moment on current topics is important for collaboration,
I would also suggest the benefits of long-term learning from past decisions can be useful.

Especially in software projects where it seems that every decade or so, there is a significant throwing out of previous efforts
sometimes ignoring the benefits of tested and working codes.  (acknowledging that sometimes spaghetti just has to GO )

Jim Houston



--
Larry Gritz
lg@...

Alien Ghost Ship Animation Studios
 

@LarryGritz, Perhaps, lol. There are implementations that will allow you to post/read like a mail list but have messages thread and show up in real time on a chat window so everyone is happy. I believe Slack has this feature, and maybe a few IRC's? Haven't used IRC in a while.

Sean Cooper
 

Am I just a cranky old man for preferring mail lists

Nope. I think its completely fair for the ASWF to just say no to real-time options.

Just the number of mile-long emails when something contentious is discussed always irritates me, especially when usually people can be calmed down and come to level ground when its a real-time interaction. So real solutions happen faster. That's all hearsay, conjecture, and personal bias of course.


It is a significant nuisance when past e-mail/posts point to dead links because of a change in the collaboration tool
 
This is precisely why I propose the ideal solution would be open source and hosted as a part of ASWF stack (sorry to maintainers in advance if that actually happens)

On Wed, Aug 22, 2018 at 6:25 PM, Larry Gritz <lg@...> wrote:
Am I just a cranky old man for preferring mail lists and dreading using Slack or IRC? They're ok for totally ephemeral "gotta do this thing right now" stuff, but I hate when actual substantive discussions or decisions for projects are made on those channels.



On August 22, 2018 10:08:04 AM PDT, Jim Houston <jim.houston@...> wrote:

On Aug 22, 2018, at 9:04 AM, Sean Cooper <sean@...> wrote:


I think you just proved that threading is a must :-)

I agree though, an option to join a channel without signing up would be great.

+1

A consistent approach among projects would be great.   I think it is difficult though to use a new startup’s tool
because they are still chasing a business model.  What features will still be present and/or advancing and which
go by the wayside.  

For a project started in 2004, I found it very useful at times to have the history of the project and 
sample images that were used still available.  It is a significant nuisance when past e-mail/posts point to dead links
because of a change in the collaboration tool.  This is true as well in SMPTE’s Kavi (higher logic) where reorganizations
have wiped clean previous threads.  Although working in the moment on current topics is important for collaboration,
I would also suggest the benefits of long-term learning from past decisions can be useful.

Especially in software projects where it seems that every decade or so, there is a significant throwing out of previous efforts
sometimes ignoring the benefits of tested and working codes.  (acknowledging that sometimes spaghetti just has to GO )

Jim Houston



--
Larry Gritz
lg@...


Darin Grant
 

I believe Larry has it correct.  Chat is amazing for quick collaboration and question answering but I suspect that these discussions are actually meant for discussions and thus belong on an email list / forum.

On Aug 22, 2018, at 10:50 AM, Sean Cooper <sean@...> wrote:

Am I just a cranky old man for preferring mail lists

Nope. I think its completely fair for the ASWF to just say no to real-time options.

Just the number of mile-long emails when something contentious is discussed always irritates me, especially when usually people can be calmed down and come to level ground when its a real-time interaction. So real solutions happen faster. That's all hearsay, conjecture, and personal bias of course.


It is a significant nuisance when past e-mail/posts point to dead links because of a change in the collaboration tool
 
This is precisely why I propose the ideal solution would be open source and hosted as a part of ASWF stack (sorry to maintainers in advance if that actually happens)

On Wed, Aug 22, 2018 at 6:25 PM, Larry Gritz <lg@...> wrote:
Am I just a cranky old man for preferring mail lists and dreading using Slack or IRC? They're ok for totally ephemeral "gotta do this thing right now" stuff, but I hate when actual substantive discussions or decisions for projects are made on those channels.



On August 22, 2018 10:08:04 AM PDT, Jim Houston <jim.houston@...> wrote:

On Aug 22, 2018, at 9:04 AM, Sean Cooper <sean@...> wrote:


I think you just proved that threading is a must :-)

I agree though, an option to join a channel without signing up would be great.

+1

A consistent approach among projects would be great.   I think it is difficult though to use a new startup’s tool
because they are still chasing a business model.  What features will still be present and/or advancing and which
go by the wayside.  

For a project started in 2004, I found it very useful at times to have the history of the project and 
sample images that were used still available.  It is a significant nuisance when past e-mail/posts point to dead links
because of a change in the collaboration tool.  This is true as well in SMPTE’s Kavi (higher logic) where reorganizations
have wiped clean previous threads.  Although working in the moment on current topics is important for collaboration,
I would also suggest the benefits of long-term learning from past decisions can be useful.

Especially in software projects where it seems that every decade or so, there is a significant throwing out of previous efforts
sometimes ignoring the benefits of tested and working codes.  (acknowledging that sometimes spaghetti just has to GO )

Jim Houston



-- 
Larry Gritz
lg@...




--
Darin Grant
Chief Technology Officer

T: +61 2 9383 4800 (main)
D: 604 398 3945 (direct)
E: Darin.Grant@...

Bld 54/FSA #19, Fox Studios Australia 38 Driver Ave
Moore Park, NSW 2021
AUSTRALIA

  LinkedIn  Facebook  Twitter  Instagram

Animal Logic

www.animallogic.com

CONFIDENTIALITY AND PRIVILEGE NOTICE
This email is intended only to be read or used by the addressee. It is confidential and may contain privileged information. If you are not the intended recipient, any use, distribution, disclosure or copying of this email is strictly prohibited. Confidentiality and legal privilege attached to this communication are not waived or lost by reason of the mistaken delivery to you. If you have received this email in error, please delete it and notify us immediately by telephone or email.

Ben De Luca
 

Too echo Larry and Darin's the joy of living in a crappy timezone where you are all mostly asleep, I hope that mailing lists can at least be the main form of communication with real-time being a supplement for the real-time interactions. 




On Wed, 22 Aug 2018 at 19:59, Darin Grant <darin.grant@...> wrote:
I believe Larry has it correct.  Chat is amazing for quick collaboration and question answering but I suspect that these discussions are actually meant for discussions and thus belong on an email list / forum.

On Aug 22, 2018, at 10:50 AM, Sean Cooper <sean@...> wrote:

Am I just a cranky old man for preferring mail lists

Nope. I think its completely fair for the ASWF to just say no to real-time options.

Just the number of mile-long emails when something contentious is discussed always irritates me, especially when usually people can be calmed down and come to level ground when its a real-time interaction. So real solutions happen faster. That's all hearsay, conjecture, and personal bias of course.


It is a significant nuisance when past e-mail/posts point to dead links because of a change in the collaboration tool
 
This is precisely why I propose the ideal solution would be open source and hosted as a part of ASWF stack (sorry to maintainers in advance if that actually happens)

On Wed, Aug 22, 2018 at 6:25 PM, Larry Gritz <lg@...> wrote:
Am I just a cranky old man for preferring mail lists and dreading using Slack or IRC? They're ok for totally ephemeral "gotta do this thing right now" stuff, but I hate when actual substantive discussions or decisions for projects are made on those channels.



On August 22, 2018 10:08:04 AM PDT, Jim Houston <jim.houston@...> wrote:

On Aug 22, 2018, at 9:04 AM, Sean Cooper <sean@...> wrote:


I think you just proved that threading is a must :-)

I agree though, an option to join a channel without signing up would be great.

+1

A consistent approach among projects would be great.   I think it is difficult though to use a new startup’s tool
because they are still chasing a business model.  What features will still be present and/or advancing and which
go by the wayside.  

For a project started in 2004, I found it very useful at times to have the history of the project and 
sample images that were used still available.  It is a significant nuisance when past e-mail/posts point to dead links
because of a change in the collaboration tool.  This is true as well in SMPTE’s Kavi (higher logic) where reorganizations
have wiped clean previous threads.  Although working in the moment on current topics is important for collaboration,
I would also suggest the benefits of long-term learning from past decisions can be useful.

Especially in software projects where it seems that every decade or so, there is a significant throwing out of previous efforts
sometimes ignoring the benefits of tested and working codes.  (acknowledging that sometimes spaghetti just has to GO )

Jim Houston



-- 
Larry Gritz
lg@...




--
Darin Grant
Chief Technology Officer

T: +61 2 9383 4800 (main)
D: 604 398 3945 (direct)
E: Darin.Grant@...

Bld 54/FSA #19, Fox Studios Australia 38 Driver Ave
Moore Park, NSW 2021
AUSTRALIA

  LinkedIn  Facebook  Twitter  Instagram

Animal Logic

www.animallogic.com

CONFIDENTIALITY AND PRIVILEGE NOTICE
This email is intended only to be read or used by the addressee. It is confidential and may contain privileged information. If you are not the intended recipient, any use, distribution, disclosure or copying of this email is strictly prohibited. Confidentiality and legal privilege attached to this communication are not waived or lost by reason of the mistaken delivery to you. If you have received this email in error, please delete it and notify us immediately by telephone or email.

Larry Gritz
 

Not to beat a dead horse, but when somebody says "real time", what I hear is "somebody important on the project, maybe even me, is going to miss it."

As I understand it, ASWF projects are intended to have a very high level of autonomy in what gets developed and how. I can't imagine that each project community wouldn't decide on its own communications style and mode. Though it's possible that for the ones who choose to have a real time (aka people left out 😜) comm channel, there may end up being an org-wide preference for which one.






On August 22, 2018 2:48:01 PM PDT, Ben De Luca <bdeluca@...> wrote:
Too echo Larry and Darin's the joy of living in a crappy timezone where you are all mostly asleep, I hope that mailing lists can at least be the main form of communication with real-time being a supplement for the real-time interactions. 




On Wed, 22 Aug 2018 at 19:59, Darin Grant <darin.grant@...> wrote:
I believe Larry has it correct.  Chat is amazing for quick collaboration and question answering but I suspect that these discussions are actually meant for discussions and thus belong on an email list / forum.

On Aug 22, 2018, at 10:50 AM, Sean Cooper <sean@...> wrote:

Am I just a cranky old man for preferring mail lists

Nope. I think its completely fair for the ASWF to just say no to real-time options.

Just the number of mile-long emails when something contentious is discussed always irritates me, especially when usually people can be calmed down and come to level ground when its a real-time interaction. So real solutions happen faster. That's all hearsay, conjecture, and personal bias of course.


It is a significant nuisance when past e-mail/posts point to dead links because of a change in the collaboration tool
 
This is precisely why I propose the ideal solution would be open source and hosted as a part of ASWF stack (sorry to maintainers in advance if that actually happens)

On Wed, Aug 22, 2018 at 6:25 PM, Larry Gritz <lg@...> wrote:
Am I just a cranky old man for preferring mail lists and dreading using Slack or IRC? They're ok for totally ephemeral "gotta do this thing right now" stuff, but I hate when actual substantive discussions or decisions for projects are made on those channels.



On August 22, 2018 10:08:04 AM PDT, Jim Houston <jim.houston@...> wrote:

On Aug 22, 2018, at 9:04 AM, Sean Cooper <sean@...> wrote:


I think you just proved that threading is a must :-)

I agree though, an option to join a channel without signing up would be great.

+1

A consistent approach among projects would be great.   I think it is difficult though to use a new startup’s tool
because they are still chasing a business model.  What features will still be present and/or advancing and which
go by the wayside.  

For a project started in 2004, I found it very useful at times to have the history of the project and 
sample images that were used still available.  It is a significant nuisance when past e-mail/posts point to dead links
because of a change in the collaboration tool.  This is true as well in SMPTE’s Kavi (higher logic) where reorganizations
have wiped clean previous threads.  Although working in the moment on current topics is important for collaboration,
I would also suggest the benefits of long-term learning from past decisions can be useful.

Especially in software projects where it seems that every decade or so, there is a significant throwing out of previous efforts
sometimes ignoring the benefits of tested and working codes.  (acknowledging that sometimes spaghetti just has to GO )

Jim Houston



-- 
Larry Gritz
lg@...




--
Darin Grant
Chief Technology Officer

T: +61 2 9383 4800 (main)
D: 604 398 3945 (direct)
E: Darin.Grant@...

Bld 54/FSA #19, Fox Studios Australia 38 Driver Ave
Moore Park, NSW 2021
AUSTRALIA

  LinkedIn  Facebook  Twitter  Instagram

Animal Logic

www.animallogic.com

CONFIDENTIALITY AND PRIVILEGE NOTICE
This email is intended only to be read or used by the addressee. It is confidential and may contain privileged information. If you are not the intended recipient, any use, distribution, disclosure or copying of this email is strictly prohibited. Confidentiality and legal privilege attached to this communication are not waived or lost by reason of the mistaken delivery to you. If you have received this email in error, please delete it and notify us immediately by telephone or email.


--
Larry Gritz
lg@...

Michael Dolan
 

FWIW, I've seen a number of communities start off by adding everyone's favorite real time service - but then they commonly end up back at email and maybe IRC for real time chat during meetings (with a MeetBot addon). 

-- Mike



On Wed, Aug 22, 2018 at 9:33 PM Larry Gritz <lg@...> wrote:
Not to beat a dead horse, but when somebody says "real time", what I hear is "somebody important on the project, maybe even me, is going to miss it."

As I understand it, ASWF projects are intended to have a very high level of autonomy in what gets developed and how. I can't imagine that each project community wouldn't decide on its own communications style and mode. Though it's possible that for the ones who choose to have a real time (aka people left out 😜) comm channel, there may end up being an org-wide preference for which one.






On August 22, 2018 2:48:01 PM PDT, Ben De Luca <bdeluca@...> wrote:
Too echo Larry and Darin's the joy of living in a crappy timezone where you are all mostly asleep, I hope that mailing lists can at least be the main form of communication with real-time being a supplement for the real-time interactions. 




On Wed, 22 Aug 2018 at 19:59, Darin Grant <darin.grant@...> wrote:
I believe Larry has it correct.  Chat is amazing for quick collaboration and question answering but I suspect that these discussions are actually meant for discussions and thus belong on an email list / forum.

On Aug 22, 2018, at 10:50 AM, Sean Cooper <sean@...> wrote:

Am I just a cranky old man for preferring mail lists

Nope. I think its completely fair for the ASWF to just say no to real-time options.

Just the number of mile-long emails when something contentious is discussed always irritates me, especially when usually people can be calmed down and come to level ground when its a real-time interaction. So real solutions happen faster. That's all hearsay, conjecture, and personal bias of course.


It is a significant nuisance when past e-mail/posts point to dead links because of a change in the collaboration tool
 
This is precisely why I propose the ideal solution would be open source and hosted as a part of ASWF stack (sorry to maintainers in advance if that actually happens)

On Wed, Aug 22, 2018 at 6:25 PM, Larry Gritz <lg@...> wrote:
Am I just a cranky old man for preferring mail lists and dreading using Slack or IRC? They're ok for totally ephemeral "gotta do this thing right now" stuff, but I hate when actual substantive discussions or decisions for projects are made on those channels.



On August 22, 2018 10:08:04 AM PDT, Jim Houston <jim.houston@...> wrote:

On Aug 22, 2018, at 9:04 AM, Sean Cooper <sean@...> wrote:


I think you just proved that threading is a must :-)

I agree though, an option to join a channel without signing up would be great.

+1

A consistent approach among projects would be great.   I think it is difficult though to use a new startup’s tool
because they are still chasing a business model.  What features will still be present and/or advancing and which
go by the wayside.  

For a project started in 2004, I found it very useful at times to have the history of the project and 
sample images that were used still available.  It is a significant nuisance when past e-mail/posts point to dead links
because of a change in the collaboration tool.  This is true as well in SMPTE’s Kavi (higher logic) where reorganizations
have wiped clean previous threads.  Although working in the moment on current topics is important for collaboration,
I would also suggest the benefits of long-term learning from past decisions can be useful.

Especially in software projects where it seems that every decade or so, there is a significant throwing out of previous efforts
sometimes ignoring the benefits of tested and working codes.  (acknowledging that sometimes spaghetti just has to GO )

Jim Houston



-- 
Larry Gritz
lg@...




--
Darin Grant
Chief Technology Officer

T: +61 2 9383 4800 (main)
D: 604 398 3945 (direct)
E: Darin.Grant@...

Bld 54/FSA #19, Fox Studios Australia 38 Driver Ave
Moore Park, NSW 2021
AUSTRALIA

  LinkedIn  Facebook  Twitter  Instagram

Animal Logic

www.animallogic.com

CONFIDENTIALITY AND PRIVILEGE NOTICE
This email is intended only to be read or used by the addressee. It is confidential and may contain privileged information. If you are not the intended recipient, any use, distribution, disclosure or copying of this email is strictly prohibited. Confidentiality and legal privilege attached to this communication are not waived or lost by reason of the mistaken delivery to you. If you have received this email in error, please delete it and notify us immediately by telephone or email.


--
Larry Gritz
lg@...

Sebastian Sylwan
 

I think both forms of communication are perfectly fine and have their place, but most importantly I don't think it's the role of the ASWF to dictate the tools to use. It is very much - I believe-- in the purview of the individual projects to decide what works best for them. 

The foundation (the TAC actually) could recommend that if a real time communication channel is used a default one should be preferred (but again not imposed), or provide an infrastructure for it, if enough projects choose the same, to encourage others to join in (for the advantages pointed up above). Same for a mailing list infrastructure.

S

On Wed, Aug 22, 2018, 5:53 PM Ben De Luca, <bdeluca@...> wrote:
Too echo Larry and Darin's the joy of living in a crappy timezone where you are all mostly asleep, I hope that mailing lists can at least be the main form of communication with real-time being a supplement for the real-time interactions. 




On Wed, 22 Aug 2018 at 19:59, Darin Grant <darin.grant@...> wrote:
I believe Larry has it correct.  Chat is amazing for quick collaboration and question answering but I suspect that these discussions are actually meant for discussions and thus belong on an email list / forum.

On Aug 22, 2018, at 10:50 AM, Sean Cooper <sean@...> wrote:

Am I just a cranky old man for preferring mail lists

Nope. I think its completely fair for the ASWF to just say no to real-time options.

Just the number of mile-long emails when something contentious is discussed always irritates me, especially when usually people can be calmed down and come to level ground when its a real-time interaction. So real solutions happen faster. That's all hearsay, conjecture, and personal bias of course.


It is a significant nuisance when past e-mail/posts point to dead links because of a change in the collaboration tool
 
This is precisely why I propose the ideal solution would be open source and hosted as a part of ASWF stack (sorry to maintainers in advance if that actually happens)

On Wed, Aug 22, 2018 at 6:25 PM, Larry Gritz <lg@...> wrote:
Am I just a cranky old man for preferring mail lists and dreading using Slack or IRC? They're ok for totally ephemeral "gotta do this thing right now" stuff, but I hate when actual substantive discussions or decisions for projects are made on those channels.



On August 22, 2018 10:08:04 AM PDT, Jim Houston <jim.houston@...> wrote:

On Aug 22, 2018, at 9:04 AM, Sean Cooper <sean@...> wrote:


I think you just proved that threading is a must :-)

I agree though, an option to join a channel without signing up would be great.

+1

A consistent approach among projects would be great.   I think it is difficult though to use a new startup’s tool
because they are still chasing a business model.  What features will still be present and/or advancing and which
go by the wayside.  

For a project started in 2004, I found it very useful at times to have the history of the project and 
sample images that were used still available.  It is a significant nuisance when past e-mail/posts point to dead links
because of a change in the collaboration tool.  This is true as well in SMPTE’s Kavi (higher logic) where reorganizations
have wiped clean previous threads.  Although working in the moment on current topics is important for collaboration,
I would also suggest the benefits of long-term learning from past decisions can be useful.

Especially in software projects where it seems that every decade or so, there is a significant throwing out of previous efforts
sometimes ignoring the benefits of tested and working codes.  (acknowledging that sometimes spaghetti just has to GO )

Jim Houston



-- 
Larry Gritz
lg@...




--
Darin Grant
Chief Technology Officer

T: +61 2 9383 4800 (main)
D: 604 398 3945 (direct)
E: Darin.Grant@...

Bld 54/FSA #19, Fox Studios Australia 38 Driver Ave
Moore Park, NSW 2021
AUSTRALIA

  LinkedIn  Facebook  Twitter  Instagram

Animal Logic

www.animallogic.com

CONFIDENTIALITY AND PRIVILEGE NOTICE
This email is intended only to be read or used by the addressee. It is confidential and may contain privileged information. If you are not the intended recipient, any use, distribution, disclosure or copying of this email is strictly prohibited. Confidentiality and legal privilege attached to this communication are not waived or lost by reason of the mistaken delivery to you. If you have received this email in error, please delete it and notify us immediately by telephone or email.

Edward Warnicke
 

Depends a lot on the communities.

While I personally prefer IRC (or did, until it started dying of spam :( ), I also participate in many communities that use slack instead.

Ed

On August 22, 2018 at 9:30:51 PM, Michael Dolan (mdolan@...) wrote:

FWIW, I've seen a number of communities start off by adding everyone's favorite real time service - but then they commonly end up back at email and maybe IRC for real time chat during meetings (with a MeetBot addon). 

-- Mike



On Wed, Aug 22, 2018 at 9:33 PM Larry Gritz <lg@...> wrote:
Not to beat a dead horse, but when somebody says "real time", what I hear is "somebody important on the project, maybe even me, is going to miss it."

As I understand it, ASWF projects are intended to have a very high level of autonomy in what gets developed and how. I can't imagine that each project community wouldn't decide on its own communications style and mode. Though it's possible that for the ones who choose to have a real time (aka people left out 😜) comm channel, there may end up being an org-wide preference for which one.






On August 22, 2018 2:48:01 PM PDT, Ben De Luca <bdeluca@...> wrote:
Too echo Larry and Darin's the joy of living in a crappy timezone where you are all mostly asleep, I hope that mailing lists can at least be the main form of communication with real-time being a supplement for the real-time interactions. 




On Wed, 22 Aug 2018 at 19:59, Darin Grant <darin.grant@...> wrote:
I believe Larry has it correct.  Chat is amazing for quick collaboration and question answering but I suspect that these discussions are actually meant for discussions and thus belong on an email list / forum.

On Aug 22, 2018, at 10:50 AM, Sean Cooper <sean@...> wrote:

Am I just a cranky old man for preferring mail lists

Nope. I think its completely fair for the ASWF to just say no to real-time options.

Just the number of mile-long emails when something contentious is discussed always irritates me, especially when usually people can be calmed down and come to level ground when its a real-time interaction. So real solutions happen faster. That's all hearsay, conjecture, and personal bias of course.


It is a significant nuisance when past e-mail/posts point to dead links because of a change in the collaboration tool
 
This is precisely why I propose the ideal solution would be open source and hosted as a part of ASWF stack (sorry to maintainers in advance if that actually happens)

On Wed, Aug 22, 2018 at 6:25 PM, Larry Gritz <lg@...> wrote:
Am I just a cranky old man for preferring mail lists and dreading using Slack or IRC? They're ok for totally ephemeral "gotta do this thing right now" stuff, but I hate when actual substantive discussions or decisions for projects are made on those channels.



On August 22, 2018 10:08:04 AM PDT, Jim Houston <jim.houston@...> wrote:

On Aug 22, 2018, at 9:04 AM, Sean Cooper <sean@...> wrote:


I think you just proved that threading is a must :-)

I agree though, an option to join a channel without signing up would be great.

+1

A consistent approach among projects would be great.   I think it is difficult though to use a new startup’s tool
because they are still chasing a business model.  What features will still be present and/or advancing and which
go by the wayside.  

For a project started in 2004, I found it very useful at times to have the history of the project and 
sample images that were used still available.  It is a significant nuisance when past e-mail/posts point to dead links
because of a change in the collaboration tool.  This is true as well in SMPTE’s Kavi (higher logic) where reorganizations
have wiped clean previous threads.  Although working in the moment on current topics is important for collaboration,
I would also suggest the benefits of long-term learning from past decisions can be useful.

Especially in software projects where it seems that every decade or so, there is a significant throwing out of previous efforts
sometimes ignoring the benefits of tested and working codes.  (acknowledging that sometimes spaghetti just has to GO )

Jim Houston



-- 
Larry Gritz
lg@...




--
Darin Grant
Chief Technology Officer

T: +61 2 9383 4800 (main)
D: 604 398 3945 (direct)
E: Darin.Grant@...

Bld 54/FSA #19, Fox Studios Australia 38 Driver Ave
Moore Park, NSW 2021
AUSTRALIA

  LinkedIn  Facebook  Twitter  Instagram

Animal Logic

www.animallogic.com

CONFIDENTIALITY AND PRIVILEGE NOTICE
This email is intended only to be read or used by the addressee. It is confidential and may contain privileged information. If you are not the intended recipient, any use, distribution, disclosure or copying of this email is strictly prohibited. Confidentiality and legal privilege attached to this communication are not waived or lost by reason of the mistaken delivery to you. If you have received this email in error, please delete it and notify us immediately by telephone or email.

--
Larry Gritz
lg@...