(Pulling @mogoodrich‘s question into the community channel)
Continuing the discussion from FHIR squad / FHIR Category:
Communication within the OpenMRS community is taking place in a lot of places. Here are a few (these are just the ones that come to mind, I’m sure there are more):
- Here on OpenMRS Talk (our forum or “mailing list”)
- IRC in Freenode #openmrs
- Pull request reviews
Historically, the prevailing “best practice” convention for open source projects was:
- Discussion on a mailing list
- Live chat on IRC
- Documentation in the wiki
@kfogel’s very wise Producing Open Source Software teaches us private discussion should be avoided except when absolutely necessary. Apache says all decisions should be shared on the mailing list (i.e., “If It didn’t happen on the mailing list, it didn’t happen.”).
When OpenMRS was born, most open source communities were using bespoke mailing lists, MediaWiki, and IRC (because IRC was the most reliable & widely available chat solution).
But, the world has changed (there are more good options now) and the world will continue to change. For this reason, I don’t think we can nor should mandate a specific medium for communication – let people use what they want; rather, we should have clear conventions to (1) always favor public discussion over private unless there’s a clear reason for privacy and (2) make sure decisions are reflected in our “mailing list” (this Talk forum). @jennifer said as much in this thread a couple months ago.
My suggestion would be:
Always favor public channels for discussions about OpenMRS. That is, if you’re using a medium that is invitation-only (email, a private Skype call/chat, or other exclusive channels), make sure there’s a good reason that your conversation needs to be private. In 99.9% of cases, this will not be the case (we’re an open source project, so, unless you’re talking about finances or human resources, it can be public).
Make sure any community decisions are documented on Talk. Discussions can happen wherever they’re most efficient/effective, but let’s try to follow the notion that a community decision not documented on Talk never happened. This doesn’t mean that all discussions need happen on Talk nor does it mean everything needs to be reiterated in detail on Talk. If we come to a decision in a private or non-archived forum, then we should strive to summarize it on Talk. If we come to a decision in a public & archived forum, then simply announce that fact on Talk with a link to the conversation for more info (any additional context/summary can be brief).
Personally, I find Talk preferable for asynchronous discussions (design feedback, working out ideas), since it’s easier to follow context, supports markdown, supports syndication (rss), is easy to search, and people can easily follow or discover discussions. Slack is great/better for chatting (synchronously or asynchronously), but, like IRC, I struggle to follow long discussions, even with its threads. But that’s a personal preference. As long as we’re not burying big decisions in tools like Slack without surfacing them in Talk, let people use what they want.
Eventually, matrix will bring it all together anyway.