From the session page:
The WordPress project both generates and processes a lot of information on a regular basis. Even for tenured contributors, it can be challenging to know where or who to go for much needed information. On each team and across the project, who should be responsible for disseminating information, and how can communication practices be streamlined to make collaboration more seamless for everyone building WordPress? This discussion will explore current friction points and possible ways to address communication and collaboration in the WordPress ecosystem.
- Explore current problems we face when communicating across teams
- Explore possible solutions to address the identified friction points
The Community faces a number of different challenges where communication and collaboration are concerned. Whether it manifests as duplicated work across teams due to a lack of communication or simply dead zones where discussions are purposely kept behind closed doors, these friction points cause real issues on all teams. While most agree we need cross-team communication, many don’t know where to go or what information is missing.
Action Items / Next Steps
- Members from different Make teams need to work together to develop a proposed process for more public communication and coordination.
- An ethical standard and code of conduct should be established to determine what information can be kept private and what we have an ethical duty to keep public.
- We should update our definition of the community to reflect what it is today, including the roles and power therein, as this informs the communication internally and externally from reps, members, and beyond.
Full Session Notes
What current problems do we have communicating across teams? What are the friction points?
- When documenting releases, the Learning and Training teams face the same issues as the Docs teams – and this often results in work being duplicated.
- It would be ideal if there was some central notification system to alert other teams on all changes. All these communications are currently in hallways or DMs.
- There is a team reps channel but it feels like it’s too official and not about coordination of information. Could it be used for this?
- Not everyone who is involved with this is a team repTeam Rep A Team Rep is a person who represents the Make WordPress team to the rest of the project, make sure issues are raised and addressed as needed, and coordinates cross-team efforts..
- Some people remain there after they’re no longer a team rep.
- Channel’s purpose is not clear.
- Is there a procedure or process that can serve to solve this? Not sure we have anything that applies to all situations…
- Each team has a weekly meeting but there is no global meeting among team reps. We need something at the project level.
- TLDR: we need cross team communication but don’t know where to go.
(SidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. conversation about what a Team Rep is, what the channel does, etc)
- Different teams use different tools – some use P2s, some use GithubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/, some use SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/., etc. How can we know the best way to communicate with each team?
- Where can people learn which team uses what?
- Note that Slack is fastest and easiest.
- There are a lot of mindset issues in the contributor community that seem to believe things that are brought forth to the community level get held up in review.
- The culture that things get done faster or better in DMs is not conducive to open sourceOpen Source Open Source denotes software for which the original source code is made freely available and may be redistributed and modified. Open Source **must be** delivered via a licensing model, see GPL. or quality.
- There’s hesitation to splinter things off into more Slack channels, but then things are lost to DMs.
- Why would you not document things? “We don’t need the community consensus so we don’t need to bring it to everyone.”
- Bringing things to the community level for cross team communication does not necessarily mean consensus is required.
- We have the ethos about how we should communicate but that’s not reflected in the actual state.
- There’s no way for a team to message only those active in their group without messaging everyone unless it’s done outside of open comms.
- During the release cycle in the release leads channel, there’s usually a check-in, which is intended to serve as a regular touchpoint among team reps.
- Team reps currently coordinate in DM groups – could there be an open team rep channel that isn’t necessarily open to everyone but is public?
- In some teams, these DMs are used for team reps past and present to share the agenda and work through items before they’re brought to the group?
- Some action items are being discussed in private – is there a security risk to not making it public?
- Some teams seem to think things need consensus before being brought to the group.
- Onboarding and team rep role definition may be a part of the confusion here.
- Some people hesitate to bring things to the public because of relationship dynamics within the team. Again, this may point to role definitions.
- In addition to invisible conversations, there are also invisible hours happening.
- Some sponsored contributors are slated to be on a specific team for 40 hours but they’re doing other things.
- Those hours are work that’s happening elsewhere and we need to do something because it’s costing teams that activity.
What we keep hearing is that we have invisible conversations and hours with Slack DMs and private channels, some make sense and some don’t seem to make sense.
The problem we’re identifying is cross team communication related, so how do we solve this without continuing to do so? Is the biggest blocker the invisible channels?
- Are any of these channels archived for public consumption? How do new team reps see what the previous team has done?
- We don’t know all the projects for all the community – each team has their own project. Is there a page where someone can check in to see what’s up?
- Consider new contributors – can they just see one page to know what the team is doing?
- That can also help other teams who don’t know the high level projects.
- If we don’t publish everything we do, they’re not available for public.
- Tribal knowledge is often lost from team rep to team rep. There seem to be responsibilities for reps that we say should be documented but there is often little interest to actually write it.
- Some teams run into other team walls because of lack of coordination, which can also be solved by working in public.
- Security team employs a traffic light protocol (red, yellow, green, clear) to help determine the level of disclosure for projects and working items. Depending on the severity or sensitivity of the issue, some matters won’t be public until after they’re resolved or in a place where they can be shared.
Discussion about the Scale Alliance that’s trying to move the project forward for Enterprise – splintering off communications also holds that initiative back from participating and helping the community grow in that way.
What do we want to suggest in a MakeWP post, which can serve as a proposal to move forward?
- We should define what a proposal really means and who should be involved, ideally while remaining public wherever possible. If we are more confident, we can define the process.
- It can go through the processes and then to leadership
- It’s not about forcing everything to be out in public – we can acknowledge those conversations that must remain public and move forward
- Have an established process
- Developing an ethical standard and code of conduct for communications
- We can establish clear criteria to define what circumstances can be kept private
- We have an ethical duty to keep things public unless that criteria is met.
- We should redefine what the community is – it’s not the same open source that it was 20 years ago with a bunch of enthusiasts on an email list. We need rules for that.
- This involves the roles and the power therein, as that informs the communication internally and externally from the reps and member