• whole team collaboration

• collective responsibility

• meritocracy
  

• mailing list

• irc channel

• daily connections meetings

• weekly community meetings

• weekly design crits 

• working group meetings

• private conversations

• pair working

• e-mail

• irc

• side-by-side

• vidyo

• etc.

• wiki

• issue tracker

• pull requests

• source code repository/documentation

• dropbox

• handbook/website/tutorials/presentations/conferences

• social media

• pirate pad/vidyo/google docs/other collaborative tools

• conversations on pull requests - transparent

• community meetings

• stretching beyond our typical domains

• Within projects important conversations are happening on mailing lists

• Jiras are well organized

• Meetings are well documented and broadcasted
  • DA: I think this is true in some cases and we can take inspiration from the GPII security work in particular and maybe some others (i.e taking good notes, posting them to wiki, and sending an email out to list with wiki link afterwards)

• Thoroughness of all resources we keep

• Conversations in the IRC channel - even when we are sitting beside each other
  • DA: and I would add the channel log - as a remote person I find the log really valuable and I check it when I've been away/offline for any period of time

• Diversity of communication channels is inclusion

• The dynamic exemplified by Alan's chart authoring pull request--so many different experiences and knowledge being contributed openly to make our stuff better, all done in a collegial and collaborative way--we especially do well with this for technical issues

• operate well as a flat hierarchy in practice
  • DA: One example of this that I've found extremely valuable is that designers are welcomed and encouraged to join discussions with developers - learning what the technical issues are and how they inform the design and generally getting an understanding of how developers work etc

• work in a distributed environment

• Participation: everyone feels motivated to share ideas and ways to improve

• Design crits: really effective way to get the whole team involved in a way that doesn't box us into titles or specialized roles--a way to talk together about design challenges and ideas
  • DA: yes! I think when we started the crits something really great happened in terms of shifting our way of working even further towards collaboration and transparency - and I think it is a tool we use to address the point about solitary, quiet contemplation combined with collaborative transparent work - the bouncing back and forth from getting feedback and input at the design crit or other group meeting and taking it back to solitary work or smaller pairings

• Echoing conversations across different forums or media--"Hey, you should check out the conversation we had in IRC," etc.

• committment to working as a community despite deadlines and etc

• respectful of each other

• anyone can join--it's not like have to ask permission or get approval--you can just join us

• we depend on github's infrastructure for our pull requests and the conversations around them

• design conversations don't have the equivalent space for permanence, openness and in context conversation connected to the artifact being discussed

• social media and reaching out to a larger community 

• we can be clearer about where we should do what******

• we should all share the responsibility for ensuring that things are happening in the correct place

• struggle to know where ops info should go

• things get stale and out of date

• meeting minutes (piratepad, google docs) are scattered

• using dropbox for design (e.g. when to move to wiki, keeping external links in sync with the dropbox artifact, etc.)

• engaging in communication with partners who may have different practices, workflows, etc.

• bring the user community into the participatory design 

• how do we get better at summarizing conversations that happen in one medium so that it becomes part of collective memory

• Recognition for "invisible" contributions.

• Can do better: reflecting the process of conceptualization--the precarious, fragile, and massively creative initial process (Elizabeth Sanders' squiggle at the "front end" of design) in a way that is amenable to lazy consensus--to the unexpected, serendipitious, and community-driven contributions without removing space for quiet, solitary, private reflection

• some inspiring possibilities related to group brainstorming followed up by quiet design in an iterative feedback cycle

• reliance on synchronous communication

• trying to figure out what tools are there and how to use it

• difference between GPII and Fluid wikis

• the various systems don't always flow and interconnect well

• all the different projects, funders, acronyms and etc. leads to confusion both internally and in terms of outreach

• wiki is very hard to search, you have to know what you want

• structure of the wiki could be better organized

• there is no search on the Infusion docs site

• find new ways to tie together different communities/collaboration forums

• some community meetings aren't structured enough

• structuring of content across google docs, wiki, dropbox etc.

• sometimes all the communictation can be overwhelming or distracting

• so hard to find and index conversations we have--"in the moment that you are having a conversation, it's the right medium. but after the fact, it might not be the right one."

• we need to make it easier for other communities to find and use our material that we share--it is open and transparent, but it may be hard to find

• how do we make it easier for the whole community to get involved

• come up with "soft" guidelines, heuristics for transparency and collaboration

• tangible design methods--so inspired by Sepideh's work on Prosperity4All's SP1; how can we continue to evolve these into living tools that self-organizing teams choose from based on the context and the design challenge--revitalize the Design Handbook from the perspective of open source co-design

• Roll our own collaborative design infrastructure:
  • use a combination of technologies to enable an open versioning system that integrates well with designer tools.
  • example: Adobe Drive CC with Git-LFS?
    

Where do we do what?

• IRC Channels
  • fluid-ops: not private, but also not logged. should be used only for things that should not be logged  i.e. real time coordination of operations tasks
  • fluid-tech: technical conversations that are not interesting to the majority of the community.  i.e. infrastructure plans and development
  • fluid-work: general conversations, sharing information, technical conversations
  • fluid-design: design conversations

How do we deal with scattered information?

• include how to communicate what we do to "outside world"

How do we get better at summarizing conversations that happen in one medium so that it becomes part of collective memory? Can we find new ways to tie together different communities/collaboration forums?

• summarize the conversation so far when moving to a new space (new channel, from private to public)
• point people to where the conversation started if it is moving
• pirate pad should be treated as temporary and should be transfered to the wiki and mailing list immediately 
• Preserve links and other relavent information from Vidyo chats in the wiki or other permanent location (put links in pirate pad and then transfer to wiki). 
• continue putting link to current pirate pad (or google doc) into IRC channel (so those who are not in the meeting can access as well)
• use the mailing list instead of emailing a select group of people
• Make use of Vidyo's recording features for saving and sharing interesting community meetings and etc.
  • may need to look into getting participant permission for recording the audio and video.
• daily connection meeting as an opportunity to share about an interesting conversation or meeting that happened and to ask questions

How do we balance community-driven contributions with space for quiet, solitary, private reflection?

Can we find a space where design conversations have the equivalent space (as github for developers) for permanence, openness and in context conversation connected to the artifact being discussed? Including live discusion and sharing of design artifacts.

• Design team will discuss what workflow works best for them and facilitates the above goals.

TODOs

• Add a channel description for fluid-tech ( Alan )
• Improve the channel descriptions to clear about what they should be used for ( Alan )
• Investigate slack or mattermost ( ? )
• Turn the notes into heuristics for community communication ( Michelle and Dana )