Meetings are just a tool to get consensus. Other tools are available but you still need to get consensus for teams to be effective. Ultimately you need issue trackers and processes for getting work defined in there. So getting consensus revolves around using those tools effectively.
A lot of OSS projects have the same need for consensus and have converged on having policies about communicating in the open and in a place where things are visible, archived, and structured. So instead of having a lot of 1 to 1 communication via email, phone, etc.: document things in an issue tracker. Have a debate on a shared slack channel or mailing list. A lot of this stuff boils down to culture.
That being said, there's nothing like some good face to face time. And meeting people once in a while helps. Doing e.g. an all hands session for communicating big decisions; having maybe a project kick off somewhere, or just meeting a couple of times a year in some location for everyone to catch up are all valid things to do.
Heh. Just today I was telling my colleagues that consensus actually isn't necessary - a lot of our decisions are so small and inconsequential (because we do small steps and thus small decisions) that getting consensus is probably too costly most of the time. We work quite well with the principle that most decisions can be made by two random developers (and have added a Slack random reply to pick a random dev in case someone needs a decision made ;-)).
Yes, it's more about providing the opportunity for people to get involved than people actually getting involved. You facilitate that by working in the open. Tag relevant people to your tickets and PRs, maybe drop a line in a slack channel, and if nobody starts arguing otherwise, you merge without having to call meetings or involving the entire team. IMHO communication and overhead needs to be proportional to the impact of the change.
For bigger teams having separate people doing the merges promotes a culture of reviews. This is exactly how OSS communities function; you don't get to merge your own PRs. Which means you need to communicate effectively to get your work in.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Meetings are just a tool to get consensus. Other tools are available but you still need to get consensus for teams to be effective. Ultimately you need issue trackers and processes for getting work defined in there. So getting consensus revolves around using those tools effectively.
A lot of OSS projects have the same need for consensus and have converged on having policies about communicating in the open and in a place where things are visible, archived, and structured. So instead of having a lot of 1 to 1 communication via email, phone, etc.: document things in an issue tracker. Have a debate on a shared slack channel or mailing list. A lot of this stuff boils down to culture.
That being said, there's nothing like some good face to face time. And meeting people once in a while helps. Doing e.g. an all hands session for communicating big decisions; having maybe a project kick off somewhere, or just meeting a couple of times a year in some location for everyone to catch up are all valid things to do.
Heh. Just today I was telling my colleagues that consensus actually isn't necessary - a lot of our decisions are so small and inconsequential (because we do small steps and thus small decisions) that getting consensus is probably too costly most of the time. We work quite well with the principle that most decisions can be made by two random developers (and have added a Slack random reply to pick a random dev in case someone needs a decision made ;-)).
Yes, it's more about providing the opportunity for people to get involved than people actually getting involved. You facilitate that by working in the open. Tag relevant people to your tickets and PRs, maybe drop a line in a slack channel, and if nobody starts arguing otherwise, you merge without having to call meetings or involving the entire team. IMHO communication and overhead needs to be proportional to the impact of the change.
For bigger teams having separate people doing the merges promotes a culture of reviews. This is exactly how OSS communities function; you don't get to merge your own PRs. Which means you need to communicate effectively to get your work in.