Skip to content
This repository has been archived by the owner on Nov 16, 2022. It is now read-only.

Guidelines and rules for communication #54

Closed
duckinator opened this issue May 17, 2014 · 4 comments
Closed

Guidelines and rules for communication #54

duckinator opened this issue May 17, 2014 · 4 comments
Labels

Comments

@duckinator
Copy link

As @whit537 mentioned in #49 (comment), there are four main areas where Gittip communicates with others:

  • Conversations we have with each other in the course of building Gittip.
  • Conversations we have about our users.
  • Conversations we have with our users.
  • Conversations we have with our business partners.

We should come up with a set of guidelines and rules, including whether to use public or private communication, for each of these situations.

@duckinator
Copy link
Author

My proposed starting points, from #49 (comment):

  • Conversations we have with each other in the course of building Gittip: we can still be transparent without requiring audio/video recordings of things. Perhaps we should look into a way to use Hangouts -- but not on-air, generally -- to discuss things, and a written summary available somewhere?
  • Conversations we have about our users: (nothing atm)
  • Conversations we have with our users: unless these are in a public medium (IRC, Twitter, GitHub), these should default to private; explicit permission before discussing publicly. On public mediums, there are special cases -- e.g., there are cases where you would want to ask before retweeting things on Twitter. There was a case earlier where I probably should have, but didn't.
  • Conversations we have with our business partners: I believe these should default to being open calls. These are the things where we may not want everyone to be able to join in, but there will be a ton of people who aren't joining in but will be interested.

@duckinator
Copy link
Author

IRC

I believe this line from @ahdinosaur in particular is noteworthy:

<ahdinosaur> i think a good solution would be for meetings to have multiple inputs: text, public video, public audio, etc all combined together in one place and editable beyond a single short timeframe.

We've tried something similar to this for our standups: combining Hangouts and IRC. I think it's a step in the right direction, but we need to combine them more directly, and have them both logged in the same place, so it's easier to look through them later on.

!m @ahdinosaur and @seanlinsley :)

@duckinator
Copy link
Author

Some notes from IRC, regarding the scheduling problem with meetings:

<Changaco> let me state the obvious regarding the schedule problem: there is no way for everyone to be in a single synchronous event
<duckinator> Changaco: no there's not. basically: we need to somehow make meetings asynchronous, without turning them into a giant clusterfuck.

@chadwhitacre
Copy link
Contributor

Reviewing old tickets. I think we're actually pretty close to having implemented this one. Current status:

  • Conversations with each other: we're basically all-GitHub right now, with periodic-but-extra Hangouts for Aspen (and we've been trying to cross-link the calls from GitHub where it matters). I guess some face-to-face as well. All binding decisions happen on GitHub, though. We could make that explicit somewhere.
  • Conversations about users: these happen in private notes on Freshdesk. Works great. Documented on "How to Support Users" (under "Protecting User Privacy."
  • Conversations with users: publicly on GitHub, or privately on email (Freshdesk). We've got a consent policy in place on "How to Support Users" (under "Protecting User Privacy." We are doing very little on marketing
  • Conversations with business partners: This is being worked out on figure out consent with third parties #411.

Here's what I'm seeing to close this ticket:

  • Say explicitly somewhere that most decisions, and certainly important community-defining ones, are expected to happen in public on GitHub (though maybe eventually Loomio, too? use Loomio #420), except for sensitive legal, safety, and security issues, which happen in private.
  • Land the consent with third parties doc (figure out consent with third parties #411).

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants