Fluid Project Communication Synchrospetive

current projects

• Security (GPII)

• P4A

• Sonification

• Assisting other people with a11y needs (e.g. PhET, Lumen)

• First Discovery Tool (PGA)

• Infusion

• Ops

Practices

• whole team collaboration

• collective responsibility

• meritocracy

Channels of communication

• 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

What do we do well?

• 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

What don't we do well or can do better?

• 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