Part I & II: Communicating…

Part I & II: Communicating on Make Team Blogs: discussions, proposals, announcements

The WordPress community communicates primarily across 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/. and Make Team blogs, commonly referred to as “P2s”. Make Team blogs in particular see an assortment of updates, discussions, proposals, and announcements. How do these come to be, and how can people provide feedback? How is the feedback considered when decisions are made? This discussion will focus on best practices around conversations on Make Team blogs.

Facilitator: @helen
Notetaker 1: @emmaht
Notetaker 2: @harmonyromo

Discussion Objectives

Discuss the current processes within the Make Team Blogs, what can be improved, how can the community be sure to reach a wider audience before making decisions.

Raw Notes

Best Practices on Make Team Blogs (P2P2 P2 or O2 is the term people use to refer to the Make WordPress blog. It can be found at https://make.wordpress.org/.) Part I

Current Pain Points:

Why do the Make Blog comments not use the BlockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. Editor (Answer: eventually it will happen – but if there are any questions, feel free to drop in any Slack channels to ask)
Raise awareness for blindspots that (newer) contributors have
Proposals – There isn’t a defined process in place. Often, the way a proposal is presented makes it seem like it’s in motion.
There is no discussion about the process to get to the proposal, no step-by-step path, and there is an implied authority when posts make it to the metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. P2.
The feel is that with a posted proposal, there is an implied absolute direction that a project is taking.
Some improvements are needed to be more considerate of other teams. Community members should have the mindset to consider what team should be included in certain decisions and proposals
New contributors don’t know about the existence of the team blogs.
There is a feeling that you must be proficient in English to partake in discussions. Possible solution: A translation button would be helpful so others can get involved
Slack is harder to follow (since information is always flowing and things are always updated), rather than project-based or 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/ issues
If you’re only contributing a few times during the week in small increments, it’s hard to find how discussions across Slack, GitHub, and Make connect to see the full picture. No one is really keeping an eye on things as a whole.
(Newer team reps) – when to keep the conversation going vs when to post on the blog. Do I link to the slack? Do I link to the github?
Lack of guidelines or general practices
Lack of visibility and ability to chime in on what other teams are doing.
Cross team decisions – project wide governance.
Proposals go up at varying times, no order, and ask for feedback for proposals, but the timeline for said feedback varies (no standardization) In comments, don’t have a standard way of moving forward, just simply look for criticisms.
When writing proposals (feature →) to pin the top comment (sometimes used and sometimes not used) – you can pin the comment that says “here is the decision that was made”
Ensuring that we are allocating the proper amount of time to comment – especially for the people who are not consistently contributing / more part time
Are there standards for who can write comments & how do other open-source projects manage this ?
RSS updates page (not linked anywhere) – any github repo that is not attached to any team – RSS are not being reported to any team right now
Who is our audience – what belongs on /updates (make/latest this will get you RSS updates) and make/projects
Who gets access, how do we ensure that people get access? And do we ensure that this happens?
Dealing with a working group vs a team, need an interim website to run surveys, (no make/blog yet), need survey tools to help with decision making. It’s a shame when decisions are made simply on Slack, versus seeking a wider perspective on make.
There need to be example templates for how to write meeting notes, proposals, etc. The Sustainability team is looking for these tools. Great to have some sort of skeleton of how to run things- centralized tools. No other place for working groups to post thoughts save for the /projects blog, so it’s hard for people to find.
Starting to contribute is soooo confusing – who is on it, who has access, still confused, people tell everyone different things.
Feedback is given – but there is no action taken afterwards, or so it seems. This can make the community feel disempowered – “why bother to comment, no one listens” while another team is saying the opposite – we need feedback, AND once there is feedback, it needs to be synthesized in a comment on the proposal post with notes on actions taken.
Fundamentally dysfunctional – there are secret meetings -instead of asynchronous meetings

IDEA:Design focus pages: A recap overview focus page could be a good path forward for sharing the full picture of what a team is doing (GitHub links, Posts, Slack discussions)

Good Experiences / Positives Experiences

Communication in WP involves having a history of discussions. The Make Team Blogs offer access to discussions from 7 years ago, and allow one to see the issues then; use this as an excellent archive.
Some individuals who were cross-team minded are able to spend time to bring groups together, but its also a weak link since so much weight is placed on one individual
During the contributor mentorship cohort, many teams worked together to support new contributors and create materials
Learn Team’s build-out has been astronomical and in future can continue to be translated for a broader audience
Easy to collaborate with another team if it’s clear how that team prefers to be contacted (Slack, GitHub, etc.)
Local sites now have the ability to have their own make/blog, worked with meta team to get it done. It is good for local communities to utilize this for onboarding, good feel for new contributors to learn how to bring content from wp.org or make/blog to translate.
Persistence is very important for teams and individuals; this is what makes things happen; this is the magic.

Best Practices on Make Team Blogs (P2) PART 2:

Sticky note exercise – everyone writes things we should keep doing, stop doing, and 1 action item.

KEEP

Openness
Wide audience to participate
Monthly recap (human touch of summaries)
Concept of cross-team communication/collaboration

STOP

Only having team reps post
Writing proposals that have already been decided
The assumption that “lack of response” is consent (lack of engagement). Announce response time remaining in regular meetings. If not objections shared, move forward after that time, but there is always room for iteration
No clarity around what is a proposal versus a confirmed project post
There is a lot of noise

ACTIONS TO THINK ABOUT

Open to experimentation as a community
Content in other languages (MLAI services to do that)
Automated translations
Easier navigation for non-developers
Allow the search to scan across all make/blogs, showing GitHub tickets, too
Organization to sum up topics (with call for actions)
Better guidelines from cross-team collabs
Common pool of assets for all teams
Proposals voted on – async and live
Show excerpts / or provide summaries or overview of all proposals submitted on projects (or in one place)
Sharing feedback (and how to give feedback)
Have DRIsDRI Directly Responsible Individual - the people who are taking ownership or responsibility for a particular project or feature.
Better UXUX UX is an acronym for User Experience - the way the user uses the UI. Think ‘what they are doing’ and less about how they do it. / UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing.
Email summary – from teams a member is subscribed to
Clarify guidelines on large project decisions – for old and new contributors
Single sign-up for updates

DISCUSSION FOLLOWING ^^ THIS

What do people think about voting?
Making sure community members are involved in the decision-making process vs ensuring we are moving forward
Keep in mind the audience of who is reading the post. Sometimes it’s for the team, other times it’s for the wider community. More refined posts announcing features.
Why have people begun feeling unsafe to share their ideas? Or that their ideas are not important? People wonder if it it their role? How do we know when and what to post? What makes someone nervous to post? Am I even allowed to post? Should a conversation start in Slack before making a post? Slack is just faster to get a response, so it’s easier to take that road vs make/blog.
Why are we using other tools? Fear of pile-on
If a decision fizzled out on github or Slack – maybe it is because it needs to be posted on Make Blog, someone might not have access
Involving your teammates is a way to post with less fear and feel like you have support behind your thoughts.
Profiles might not align – so it looks like you have no credit because it’s in a different place
We can build on the ideas on posts (where decisions are made) – leaving a footprint/legacy for future decision. Ex: training team – WP certification (conversation happened about 3 years ago- didn’t go away, had the convo again, still didn’t go anywhere – but it its documented and we were able to build on. So, it wasn’t a wasted post. Can we encourage people who post – that no post is a dud post? Building more value there
On learn – we can support by offering: How to write a well-written proposal
Tip: Link to ALL of your posts that are relevant – so people can see what was already discussed (Slack, Twitter, etc.)
Offer guidance on “How to kick start a working group & How to give good feedback”
Proposals that take off – but then fizzle out – but no communication on WHY it fizzled out (there is no communication or follow-up), so there is no closure
Summary ideas: Perhaps AI can assist in this summary posting. Design- this was the week’s topic, this decision was made, etc. Something to consider, given that the majority of the contributors are not funded and volunteering their time.
Why use that time to publish summaries rather than the project?
Sponsors vs individual – sponsored could assist with the “glue work” – not actually doing the “work” but making sure that someone somewhere is doing the work and keeping the community updated on what is actually happening on certain projects.
Caution should be exercised when looking at the AI tools out there that could be leveraged…many are not 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., so that goes against the ethos of the project. Find a balance.

THOUGHTS ON VOTING

PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. https://www.php.net/manual/en/preface.php. – does formal requests for comments
Structure helps get things done
End of the month voting on projects (proposals are submitted during the month), then have amendments
We are missing constructive debate with yes/no voting
We need a space (create a space) to have this “debate” with a deadline
Not always a “simple majority”
There are by-laws (like 2/3s)
Can change per project (only contributors etc.)
How would you get past that WP is more of a consensus vs a majority

Questions Raised:

Why are we using so many external tools for discussion (GitHub/Slack) versus the make.wordpress blog?

How do we make sure that all necessary parties are involved in making a decision? If we have a discussion only in Slack, this surely will exclude certain people, however, many people aren’t made aware of the make.wordpress blogs for each team.

Conclusions/Summary:

Onboarding needs improvement so newcomers are made aware of the make.wordpress blog and how it is used across teams, as well as how to get involved in the conversation.

There needs to be more balance with efficiency and flow of posts, especially with proposals. There should be standard guidelines related to comment periods, then follow ups to those posts with information on steps taken or not taken and decisions made.

It’s important to make the planning visible (project boards, etc) across teams
The community needs periodic summaries from each team so they can come in and know what’s been happening and what’s coming next

There needs to be clear ownership and responsibility as this is a positive thing to have (have DRIs)