opensourcedesign / organization

:clipboard: Organizational topics for the Open Source Design collective
http://opensourcedesign.net/organization/
GNU Affero General Public License v3.0
93 stars 27 forks source link

Create various group@opensourcedesign.net email forwarders #63

Closed bnvk closed 7 years ago

bnvk commented 7 years ago

Cases emerge where conversations regarding OSD start to happen in email channels, and these conversations stay in email channels amongst just the people initially involved. I would very much like to offer a way to loop others in that is efficient + privacy respecting such as group forwarders. Some suggested addresses are:

I can help you do this via various email services I'm familiar with. @jancborchardt you have access to the domain name, yes?

jancborchardt commented 7 years ago

I would like to keep as many interactions in the open as possible, so I would say we should do this on a very specific case-by-case basis.

For example, can you list the reasons we need these handles? I understand conduct@ for reporting violations of the code of conduct, and events@ would be useful for contacting venues. Tasks and so-called »core« discussions should be public though if we want to grow our community. :)

elioqoshi commented 7 years ago

I do think we need some privacy when discussing things like working together with OSI or other "Open Design" groups as the topics can be quite controversial and missunderstood if not looped in right.

@bvnk @jancborchardt I think you know what cases I meant here as an example

ei8fdb commented 7 years ago

Totally agree with @jancborchardt's points.

Yes email addresses/forwarders are useful for dealing with interactions with people/companies outside OSD, but I don't see why tasks and decisions can't be handled in a Kanban board/issues tracker.

All (most) of the work process stuff I do in the gov department I work at is held in a Trello board(s). People can then see whats there.

elioqoshi commented 7 years ago

Yes email addresses/forwarders are useful for dealing with interactions with people/companies outside OSD,

I think that's the use case Brennan described here.

evalica commented 7 years ago

I prefer doing things in the open and I don't think we need the above mailinglists.

simonv3 commented 7 years ago

What if we had an e-mail address that automatically posted a github issue to a "contact" repo when it receives an e-mail?

Main concern there is spam, but if it's gmail it might be pretty good at filtering out the spam.

elioqoshi commented 7 years ago

I prefer doing things in the open and I don't think we need the above mailinglists.

I assume that doesn't mean that we are discussing this to close up some discussion? There is a fine line between transparency and privacy, especially for controversial topics which are related with relationships between people or even drama, which I'd rather not have on a public forum, frankly. And sometimes I get the feeling that a discussion might slip into that category.

I'd rather say that openness is like chocolate. It's great most of the time and there is always place for it. But sometimes it's not the right time and place for chocolate :)

bnvk commented 7 years ago

Since core@ exists now, that is sufficient so closing (for now)!

jancborchardt commented 7 years ago

Since we are transparent about all our decisions, here’s the people currently being part of this core@ forwarder, and their Github handles. Next to it also the reasoning for their addition to this list, as reference and also to get to know each other more :) (let me know if I forgot anything)

As per discussion on https://github.com/opensourcedesign/organization/issues/63 this is strictly for stuff we can’t talk about in the open, which will occur very rarely. But some examples:

This is absolutely NOT for anything which belongs in the open. I expect us to use it only a few times a year. :)

simonv3 commented 7 years ago

Should we list the above somewhere more publicly like on our website?

jancborchardt commented 7 years ago

@simonv3 I think so, at least on the Code of Conduct report page. Otherwise I’d still prefer that we don’t refer that often to a »core« group except when necessary.